For Mastodon there is something called Tootpick which allows you to enter your server's domain and share any content by redirecting the user. For example: https://tootpick.org/#text=https://eventfrontier.com/post/37808. So I'm not quite sure the federated nature argument makes sense. Sure it's more complicated that a centralized system, but possible regardless.
My guess is this is the service that has the backlink feature in the top left near the time. So when you open an app, you can easily go back to the previous app.
But, it seems like a bug in iOS that this shows up in your screen time.
Feels like this would just be adding on a centralized feature to a system designed to be decentralized. If anything, it should be based on a decentralized system like Bitcoin or something.
Personally, that isn’t how I think about a smart home system. There isn’t a need to do major changes until maybe you need to get it replaced anyways. Starting with things like lights, a few shades, door sensors, are good ways to start. The biggest question is what do you want to get out of it?
The craziest thing is that Elon’s tweets are still completely visible.
So if you were moving to another home or apartment, is it a reasonable strategy to stop paying rent at your current home while you’re looking for a new place? Of course not. Same idea here.
@MentalEdge@sopuli.xyz If the instance is overloaded, how do you still get posts then?
Does the subscription being pending remove any functionality or change the behavior at all?
I have a lot of them from Beehaw.org. What I didn't expect is I still seem to be seeing posts from those communities in my subscribed feed.
@dessalines@lemmy.ml Thanks for the information here and all the hard work you have put into this release.
Gotta say tho, as the maintainer of Lemmy-Swift-Client, breaking API changes like this without an API version bump, make API development within the community incredibly difficult.
So my question to you would be, what is the purpose of having v3
in the API path, if the true test of API compatibility is the GetServerResponse version
field? And breaking changes will occur in GetServerResponse version
changes as opposed to the version in the API path? That doesn't quite make sense to me.
Would love your perspective so I can figure out how to best design the package API to accommodate client developers who might have to contend with multiple server versions.
Doesn't sound like you've given any reasons against it?