Meh, just run several associated services and keep the same username on all of them. Nothing is interoperable, stop trying to force it. And a rogue app with bad user data handling practices is still going to leak your data, even if you store your copy of the data securely.
My fediverse accounts are always “patrick@<service>.bestiver.se”. I currently am only running Mastodon/Lemmy and a few supporting services (e.g. a link manager - https://bestiver.se/@patrick), but I’m adding more as I get to them. Pixelfed, Peertube, Loops(?), Piefed…
Adopting this ActivityPods thing looks like it will require each Fediverse project to make what I’d guess are fairly significant changes to their user data handling, and none of those projects are properly funded for this. In fact what this actually seems to be doing is asking every other Fedi app to build on top of their user data API.
I applaud the attempt at building a new standard in the Fediverse, but I doubt it’s going to happen.
I think there are some misconceptions here.
ActivityPods does not build a new standard but actually implements existing ones instead (ActivityPub and Solid).
So if you are a dev, you can write your own app on top of ActivityPods and it gives you the ActivityPub support almost “for free”. This gives you:
(1) freedom of the users where they have their account when logging in to your app (like a sign in with google) but the user data is stored with the user’s personal online datastore (POD) not with the app
(2) the possibility to deploy multiple instances of your app which can be useful to build communities independent of the account provider.
Also (3) as an app dev, you don’t need to worry where to store users’ data.
For an existing ActivityPub application (take mastodon for example, we have an alpha stage app called mastopod which is intended for microblogging), there is nothing to do actually. If someone builds an app that supports the same types, for example the Article or Event type of ActivityPub (/ActivityStreams), they can understand each others activities.
You could for example imagine an app that functions like an aggregator for all types of Activities and all people you follow but you might want your blogging app to only show you Articles. And another app that is nice for organizing events.
All it would require is someone making an app on top of it the same way the devs built Mastopod. They built it on top of SemApps which makes it relatively easy to built apps on top of ActivityPods
Meh, just run several associated services and keep the same username on all of them. Nothing is interoperable, stop trying to force it. And a rogue app with bad user data handling practices is still going to leak your data, even if you store your copy of the data securely.
My fediverse accounts are always “patrick@<service>.bestiver.se”. I currently am only running Mastodon/Lemmy and a few supporting services (e.g. a link manager - https://bestiver.se/@patrick), but I’m adding more as I get to them. Pixelfed, Peertube, Loops(?), Piefed…
Adopting this ActivityPods thing looks like it will require each Fediverse project to make what I’d guess are fairly significant changes to their user data handling, and none of those projects are properly funded for this. In fact what this actually seems to be doing is asking every other Fedi app to build on top of their user data API.
I applaud the attempt at building a new standard in the Fediverse, but I doubt it’s going to happen.
Good points
I think there are some misconceptions here. ActivityPods does not build a new standard but actually implements existing ones instead (ActivityPub and Solid).
So if you are a dev, you can write your own app on top of ActivityPods and it gives you the ActivityPub support almost “for free”. This gives you: (1) freedom of the users where they have their account when logging in to your app (like a sign in with google) but the user data is stored with the user’s personal online datastore (POD) not with the app (2) the possibility to deploy multiple instances of your app which can be useful to build communities independent of the account provider. Also (3) as an app dev, you don’t need to worry where to store users’ data.
For an existing ActivityPub application (take mastodon for example, we have an alpha stage app called mastopod which is intended for microblogging), there is nothing to do actually. If someone builds an app that supports the same types, for example the
ArticleorEventtype of ActivityPub (/ActivityStreams), they can understand each others activities. You could for example imagine an app that functions like an aggregator for all types of Activities and all people you follow but you might want your blogging app to only show youArticles. And another app that is nice for organizing events.All it would require is someone making an app on top of it the same way the devs built Mastopod. They built it on top of SemApps which makes it relatively easy to built apps on top of ActivityPods