It feels suboptimal that each fedi service requires a different account.
-
It feels suboptimal that each fedi service requires a different account.
e.g. I have a Flohmarkt instance, which is different from my Mastodon instance. If I also ran a pixelfed instance, that would be a third account.
Rather than one "me", with different linked services.
Perhaps there is a need for an opt-in fedi directory service / "main" account, which people can use for discovering of sub-accounts?
Or perhaps this is just web-finger or .well-known, in some way?
(I can see that, for some users, separation of accounts will be valuable, so I wouldn't want to remove that ability.)
-
completely agree, and why I wish activitypub had a native SSO-style service, or something
any one activitypub service could act as a user-selected "root" identity from which to base other accounts on
-
@neil for me, I wish there was a broader activitypub server that could interact with different clients in different ways, as needed.
Following my server with a pixelfed client - here's my photos.
Following with a microblogging client - here's my notes timeline.
Etc etc.
I want one big activity stream that behaves in different ways with different clients.
-
R [email protected] shared this topic
-
O [email protected] shared this topic
-
@basil @neil I think the issue is that not all activities are understood by all clients.
mastodon has no concept of a downvote, lemmy does.
forgejo has repos, with lots of collections / deltas that mastodon can only partially understand.
threads and groups roll up different in bonfire
mobilizon's calendar things aren't quite the same UI as others
there shouldn't need to be one server that can validate every activity,
but each individual app should speak a federated dialect
it does not need to be the same dialect.
-
@neil one account for everything is exactly how activitypub is *supposed* to work.
Then everyone ignored the client to server API and did their own things -
-
-
-
Raphael Lullisreplied to Evan Prodromou last edited by [email protected]
Let me set the right expectations. I took all the work I did to get https://cupid.careers federated and turned it into a standalone Django application. It does not yet implement C2S, but the plan is to have a generic AP server with a system to let accounts register their own actors.
I am taking a lot of inspiration from https://codeberg.org/Vocata/vocata (h/t @nik) and hope this paves the way to my idea of a "Social Web Browser".
-
I was hoping to get a bit of documentation to make a proper announcement, but that will have to come later. Just to keep my promise, though:
https://github.com/mushroomlabs/django-activitypub-toolkit
