We're working on it! Here's the spec-in-progress: https://www.w3.org/TR/did-core/
These things take time. We'll get there.
this post was submitted on 27 Jul 2023
85 points (94.7% liked)
Fediverse
28380 readers
779 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
Barely understood it, but thanks for your work!
A unified API and a single login, are two separate things.
A single federated authentication could be a good idea. But the various federated services are different enough that they should have different APIs.
OP is just asking why they a third party mastodon app can't login to a Lemmy or kbin server, which is a valid question.
From an authentication standpoint there's no reason for their auth flows to be at all different or use different endpoints relative to their domain.
The returned profile or account object might have different fields which could cause an app to crash, but there's no reason for every fediverse app to not use some of the same basic schemas and endpoints.
Yes, they are completely different things.
I'm not an expert, those who know more, please correct me.
Regarding logging-in with one account into another instance, I think that's not how it's intended to work. But I'm oot sure I understand what you're asking.
Regarding the unified client API, 2 days ago Manton Reece (Creator of Micro.blog) wrote a response to Dave Winer's open voicemail in where he says:
There is a lot of work to do, even outside of ActivityPub. As Dave mentions, we also need a common posting API. The most popular Mastodon client apps do not support either ActivityPub or Micropub. But a lot of progress can be made focusing on interoperability for the server-to-server part of the API. That should be the top priority with Threads set to join the fediverse.
logging in with one account into another instance
I'd imagine a OAuth/JWT-like workflow, where pixelfed.social can ask a kbin-API whether my user exists on kbin.social.
If it does, I should be able to post images on the pixelfed app that show my username as @adonis.
Edit: by @adonis, I mean adonis @ kbin.social
If it does, I should be able to post images on the pixelfed app that show my username as @adonis.
It cannot work as stated because there could be another @adonis accounts in other instances and the only way to prevent that would be to centralize all the signups which goes against the whole idea of decentralization. That's why the user must be @adonis1@kbin.whatever as it is shown now.
Regarding the OAuth/JWT, again... not an expert, but what I understand is that that kind of integration is much stronger than the current system. AFAIK, it could work as you say, but that would make things much more complex for the servers; you usually provide OAuth authentication for a few services, I don't know how well that scales with ... hundreds / thousands (?) of authentication provders. But, who knows, maybe in the future it's implemented in one way or another.
We should take into account that this technology is fairly new and people are still building on it.
Sorry but the autoformatting miscommunicated my statement... by @adonis I meant adonis @ kbin.social.
And the domain is always part of the actual userhandle. Hence, there can only be one.
Regarding OAuth/JWT, these aren't new concepts. They've been around for while, if not decades.
Here is the reason: https://xkcd.com/927/
Fine ill go make my own standard but with black jackc and hookers
There is a comic for everything
Pixelfed actually got a sign in with Mastodon account working:
yeah... and all it really does is create a new pixelfed account, while copying over the mastodon bio and followers.
ActivityPub has a C2S (client to server) API in addition to the S2S (server to server) API, it's just that nobody cared about it to implement it. And because nobody implemented it nobody iterated upon it so now it sits as this underspecified (and unusable) state.
Because they are still different apps with different needs, architectures and formats. They just synchronize most of their content between each other.
they just synchronize
But to be able to sync with each other, they still have to agree upon a standard, right?
Yea, but that's just a lowest common denominator (e.g. it doesn't include things like lemmy community sidebars), and also generally not appropriate for a client application. ActivityPub transmitts all events that are happening (posts, likes ...) between servers, and they are supposed to index and aggregate things (e.g. sum up votes, sort posts). It's just not feasible to expect the same from a mobile app for example, you'd have to at least create another standard for that.
So services end up implementing their own client APIs to fit their needs. And imo that's actually a good thing, because it allows them to try out features and specialize on different use cases. But afaik the ActivityPub people are working on another standard for client APIs, at least it's on their radar.
b
Only if W3C people thought about all this.. before releasing ActivityPub protocol to the public.
view more: next ›