In response to Bray’s toot, Evan Prodromou — one of the creators of ActivityPub, who is currently writing an O’Reilly book about the protocol — noted that this “is also the argument for using the ActivityPub API.” He described the API as “an open, extensible API that can handle any kind of activity type — not just short text.”
This gets to the nub of the issue. The fact that I can’t use my Mastodon identity to, for example, sign up to Pixelfed is not actually an ActivityPub issue — it’s because the two applications, Mastodon and Pixelfed, each require you to create an account on their respective products. What Prodromou is suggesting is that, technically, you can use the ActivityPub API for account access.
Wow, can’t wait to get banned in 1 instance and that ban cascading to federated fediverses(?) (through fediverse ??) and getting banned everywhere.
How about?:
Fediverse > Fedigalaxy > Fediplanet > Fedicountry
ActivityPub > Platform > Instance > Community
I prefer:
Fediverse > Fedichorus > Fedibridge > Fedichorus
If any federated banning networks do pop up, I’d expect them to form groups, with different groups having different standards. And the idea being that if someone’s banned from one place with similar standards, the rest of the group probably wouldn’t welcome the content.
It’ll come down to places and groups being reasonable, and not banning for stupid reasons (at least by that group’s standards). And if they are unreasonable, it’ll reflect on the group, as nobody would bother posting to those instances any more.
And in a way, the ultimate “ban” will be with the host instance, similarly to email.
An admin at lemmy.world might get a report that an account is spreading csam links everywhere, and to consider banning them, for example.
If we have that, we have millions of users.
That’s what I was thinking. It would make it really way for Threads users to try out the various corners of the Fediverse and they are still with Meta because of a demonstrated liking for convenience.
Then you introduce easy account migration so we can offer them greater privacy without losing out of access to their Threads account.
The Fediverse would need to make sure their servers are up to the task of on-boarding all the new users we’d be poaching.
A “portable identity” or account that one could use between federated services would be pretty spiffy.
“ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.”
I can’t see how Apub’s C2S API can realistically be implemented. It’s fairly light on details and if I’m understanding it correctly the only standard way to get activity from the server is to pull from an actor’s inbox, which has to be an
OrderedCollectionof all the activity the actor has received (likes, notifications, posts, the lot). This shifts a lot of the work to clients which, apart from being being very classist, is very limiting for implementations.
