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
57 points (93.8% liked)
Fediverse
27820 readers
842 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.
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.
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. 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.
Here is the reason: https://xkcd.com/927/
Fine ill go make my own standard but with black jackc and hookers
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.
Only if W3C people thought about all this.. before releasing ActivityPub protocol to the public.
Most Fediverse apps implement the Mastodon API. Lemmy and Kbin are kind of weird in that they don't, but their upvote based system doesn't really stroke with most existing Fediverse applications anyway.
ActivityPub does have a client-to-server API but very few servers actually bother to implement it and it's very barebones. I believe Akkoma supports it and a few experimental servers that don't have a user serviceable frontend, but that's about all I know.
In theory this stuff isn't really necessary. There's no reason why you can't combine the ActivityPub queues for different servers, allowing you to use the same account everywhere. This would need to submit outgoing content back to other services to keep them in sync and possibly proxy and keep track of posts hosted behind the proxy to make sure duplicate IDs don't become a problem, but it can be done.
A theoretical fix for this would be to proxy all ActivityPub requests for different services hosted on a website through a program that will do the actual federation work. I practice, following a single Lemmy server will cause your entire Mastodon timeline to be comments to posts you can barely even see. The flat list approach Mastodon and most Fediverse applications take doesn't work well with hierarchical posts Lemmy and Kbin offer. Try following a few Lemmy/Kbin communities and you'll see what I mean.
In practice, everyone is doing their own thing. The single sign on options work like logging in with Google/Facebook/Twitter does, creating new accounts without passwords you can use from a single place.
As for the technical reason why you can't use the same username@domain for multiple services: ActivityPub, the protocol federating most Fediverse servers, works by using WebFinger to look up an account based on an account name. This will let an external server obtain the location of your account details.
Your account details contain a number of collections (posts, likes, favourites) that can be fetched remotely. How these are made available is up to the individual server. Mastodon, Lemmy, Kbin, and every other tool all contain code to generate the JSON documents that comply with this format.
However, these tools are all different internally. Different programming languages, different database layouts, different database engines, different features and protocol extensions, different URL formats, different post IDs, different everything. You can't just point Pixelfed at a Mastodon server and tell it to go fetch some content, because Pixelfed's client-server API is different from Mastodon's.
With extensive work, these tools can all be made to work together under a single username. Every tool needs to be made aware of every other tool, and a lot of the actual federation code needs to be externalised to an all-encompassing server. This can be done without breaking any spec and without becoming incompatible with the rest of the Fediverse, but it'll require a LOT of work.
If you have the skills to make these modifications, or the money to pay people with those skills, you can make it happen. It's just not something different Fediverse servers are going to put a lot of effort into any time soon.
> With extensive work, these tools can all be made to work together under a single username. Every tool needs to be made aware of every other tool, and a lot of the actual federation code needs to be externalised to an all-encompassing server. This can be done without breaking any spec and without becoming incompatible with the rest of the Fediverse, but it’ll require a LOT of work.
You basically summarized my original plan for communick. The basic idea is:
- Take the existing services, provide commercial hosting
- Use the revenue to fund development of protocol-level integrations, contribute back to open source
- Build tools to make it easy for companies to migrate away from Facebook/Twitter/Instagram/WhatsApp and own back their internet presence again
- ???
- Profit / Destroy Big Tech.
Unfortunately, the amount of people willing to pay for commercial providers of social media is embarrassingly small, so I am stuck at step 1 and the best I could do is to build a SSO system for Matrix/Mastodon/XMPP, to let people use the same credentials on all "communick.com" servers.
I've been thinking of writing up a script to deploy a single Mastodon+Matrix+Kbin+whatever service through Keycloak and something like Ansible, but OAuth2 implementations seem to mostly focus on big social media companies rather than arbitrary SSO. Matrix has native SSO support, but even XMPP doesn't seem all that well set up for federation (maybe an XMPP bridge would help?).
I don't have time to put into this idea and I don't think it makes much sense as a business model, sadly. There isn't much interest in hosting your own socials. That said, with Threads and Tumblr coming in, I can see a potential for mainstream users. I don't think they'll be interested, but imagine a tech brand like LTT coming in with a federated forum for customer/community interaction, Matrix for chat, Mastodon for social media outreach, all behind one secure login system, delivering content and community to the Fediverse, Threads, and Tumblr. Perhaps integrate this with a Twitter API client for an appropriate price to help web care resolve the signatures at the end of messages ("^FL") by using the domain name as a verification system and the agent's username rather than adding signatures everywhere.
It's going to be a tough sell, but with a bit of luck and a few years of growth I think it may happen. You'd also need to loop in platforms like Bluesky over course, which will be more difficult but it's still technically feasible.
I was also considering taking a lightweight Matrix implementation (Hydrogen?) and stuffing it into a Lemmy frontend to provide more secure DMs. That's more work to maintain long term, though.
> imagine tech brand like LTT coming in with a federated forum for customer/community interaction
Exactly! This also applies for old media as well. Why is it that the NYT, WaPo, WSJ, Deutsche Welle, Globo, Telemundo, Forbes et caterva haven't still set up their own AP servers? I guess they seem as more interesting to go to Twitter and bitch about Elon Musk instead of just emptying the platform? Why can't they become providers of a service and say "all subscribers get a free account"?
Currently, the entire Fediverse is equal to what, two percent of Twitter's userbase? Maybe 10% if you take out all the Twitter bots? Twitter is used for outreach, but with nobody to follow you, there's no incentive for companies to join the Fediverse.
This can change once some social media with actually relevant user bases start joining the network (Threads, Tumblr) but until then I wouldn't expect any companies to bother.
I don't think it'd be a good idea to put journalists on an instance with their publication, though. Sure, they should use the verification feature Mastodon provides, but you don't want a journalist's socials to be in the hands of their boss.
Complaining about 𝕏 makes sense for as long as there are more active people on there than there are on any of their competitors. People don't want Twitter do die and wither away, they want it to go back to the way things were before mister "make se𝕏ual assault cases to away by giving her a horse" took over.
> the entire Fediverse is equal to what, two percent of Twitter’s userbase?
I'd honestly say it's even less and I'd even wager that the amount of bots here are even higher (percent-wise) than Twitter. I'm working on a search engine for the fediverse now, and I was surprised with the amount of bot accounts and mirror servers that I am finding.
> you don’t want a journalist’s socials to be in the hands of their boss.
I feel quite the opposite. If a journalist is really independent, then they can go on to host their own content. But as long as they are writing under the editorial guidelines of some larger institution, I want this association to be well defined and transparent.
> People don’t want Twitter do die and wither away.
I am fundamentally opposed to any ad-funded business. I honestly believe that moment a lot of the issues in our society can be traced back to the moment that we made it possible for people to make a living by just collecting eyeballs instead of focusing on quality work at a small scale. So, yeah, I very much want Twitter/Facebook/Google to die and wither away.
My limited view on the Fediverse makes it seem very human operated, but I'll trust your judgement given your experience in these matters. I don't trust the statistics (2 million active Lemmy users, but Lemmy feeds drying up after two or three pages? No way!) but the accounts I do see just feel more genuine, I guess.
As for journalists, verification is key. I haven't seen any journalist that wouldn't voluntary write the publication they work for in their bio. Mastodon provides a way to verify your relationship with an arbitrary web page (i.e. https://news.example/people/f.m.lastname) by providing a special value in the page HTML, regardless of what server they're on. I think that would be an excellent solution.
I agree with you on ad based services, but I don't think we're in the majority here. No matter how much people complain about ads and tracking, they just don't want or can't afford to pay for the services they're using. This only leave predatory money making tactics if you want to make money off the content you create. When 𝕏 dies a slow death, Bluesky's enshittification will begin.
b
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.
view more: next ›