Ideas about how to tackle the biggest problems in the fediverse.
Over the years, I’ve been studying a handful of different fediverse platforms that bring a lot of interesting concepts to the table.
As someone that has studied and reported on the developments of these various systems, I’ve decided to put together a summary of things I’d like to one day put into my own federated platform, should I ever develop enough brainpower to actually develop one.
Agreed 100% on the account proliferation and type asymmetry points. The way things stand, right now, the user’s choice of account provider will determine what actions they can take on the fediverse as a whole. It is a wholly unfortunate state of things.
An interesting exception would be Owncast’s “Fediverse auth” option for stream chatting. That sends a One-Time code to your mastodon inbox for authentication.
As @jackalope@lemmy.ml suggested, Solid would be a shoo-in for your “User Data” server. If, that is, Solid could shake off some of its sheer conceptual gravity. People say the fediverse has a geek problem, i.e. only geeks use it. Well, I think Solid has a worse version of that problem. It is only approachable by the deepest loremasters of geekdom. They are also still vague on its actual operation. What’s more, they are still deliberating what their actual security model will look like.
Which makes me sad, because the Solid sounds exactly like what we architecturally need.
EDIT (3:25 am EDT): Just wanted to add on here, I really think that “linked data” and SPARQL were bad, possibly self-defeating decisions for the Solid project. I sorta see their motivation–they want that sweet, sweet flexibility. But I think this approach is not a good solution.
I think you’re spot on with account thing. When I first came to the fediverse, I thought the distributed system was cool, but then I saw the interoperability between different software and though ok, but why would I want to?
If someone posts a peertube video within the medium of lemmy, I also want to discuss it within the medium of lemmy, after all, there’s a reason they posted it here. I want to do it in this community, using this identity. If I wanted to comment on peertube, I would go to peertube.
So the only benefit I saw was that you could use one account for all my social media, as convenience. But of course, that’s not how it works. The interoperability is just a half baked sending messages thing. Because they are fundamentally different platforms not carefully designed to work perfectly with every other platform in the fediverse. There’s no central account, you sign up for a specific software, on someone’s instance.
Lots of the things you mention are as you are probably aware already in Hubzilla. But I think it is safe to assume that those will not see much uptake in the wider AP ecosystem.
As for federated accounts, I think the most feasible is probably some sort of out of band login option similar to how those login with google (OIDC) exists. However OIDC specifically does not work without such centralization.
I think Matrix is working on something less centralized like that and XMPP had a solution for that since many years that allows you to log into a website password less with a confirmation message via your IM client.
Epicyon already does have hashtag topics, except that they’re called “categories”. They’re also published as an RSS feed by the instance, so other instances can bootstrap off of the categories assigned by others.
A community dedicated to fediverse news and discussion.
Fediverse is a portmanteau of “federation” and “universe”. It is a common, informal name for a federation of social network servers whose main purpose is microblogging, the sharing of short, public messages.
Agreed 100% on the account proliferation and type asymmetry points. The way things stand, right now, the user’s choice of account provider will determine what actions they can take on the fediverse as a whole. It is a wholly unfortunate state of things.
An interesting exception would be Owncast’s “Fediverse auth” option for stream chatting. That sends a One-Time code to your mastodon inbox for authentication.
As @jackalope@lemmy.ml suggested, Solid would be a shoo-in for your “User Data” server. If, that is, Solid could shake off some of its sheer conceptual gravity. People say the fediverse has a geek problem, i.e. only geeks use it. Well, I think Solid has a worse version of that problem. It is only approachable by the deepest loremasters of geekdom. They are also still vague on its actual operation. What’s more, they are still deliberating what their actual security model will look like.
Which makes me sad, because the Solid sounds exactly like what we architecturally need.
EDIT (3:25 am EDT): Just wanted to add on here, I really think that “linked data” and SPARQL were bad, possibly self-defeating decisions for the Solid project. I sorta see their motivation–they want that sweet, sweet flexibility. But I think this approach is not a good solution.
EDIT again: added links
I wonder if Solid could be used to deal with federated ID?
I think you’re spot on with account thing. When I first came to the fediverse, I thought the distributed system was cool, but then I saw the interoperability between different software and though ok, but why would I want to?
If someone posts a peertube video within the medium of lemmy, I also want to discuss it within the medium of lemmy, after all, there’s a reason they posted it here. I want to do it in this community, using this identity. If I wanted to comment on peertube, I would go to peertube.
So the only benefit I saw was that you could use one account for all my social media, as convenience. But of course, that’s not how it works. The interoperability is just a half baked sending messages thing. Because they are fundamentally different platforms not carefully designed to work perfectly with every other platform in the fediverse. There’s no central account, you sign up for a specific software, on someone’s instance.
Lots of the things you mention are as you are probably aware already in Hubzilla. But I think it is safe to assume that those will not see much uptake in the wider AP ecosystem.
As for federated accounts, I think the most feasible is probably some sort of out of band login option similar to how those login with google (OIDC) exists. However OIDC specifically does not work without such centralization.
I think Matrix is working on something less centralized like that and XMPP had a solution for that since many years that allows you to log into a website password less with a confirmation message via your IM client.
Epicyon already does have hashtag topics, except that they’re called “categories”. They’re also published as an RSS feed by the instance, so other instances can bootstrap off of the categories assigned by others.