Is decentralised federated social media over engineered?

Can't get this brain fart out of my head.

What would the simplest, FOSS, alternative look like and would it be worth it?

Quick thoughts:

* FOSS platforms intended to be big single servers, but dedicated to ...
* Shared/Single Sign On
* Easy cross posting
* Enabling and building universal Multi-platform clients.
* Unlike email, supporting small servers

No duplication/federation/protocol required, just software.

#fediverse
@fediverse

all 25 comments

sorted by: hot top controversial new old
[–] 15 points 2 years ago* (1 child)

Single sign in to the fediverse seems awful. Then we are logging in to it through American big tech servers. Forget anonymity and no tracking. Probably see ads on the login screen too.

But otherwise, sure. A single server is not always a bad idea. In practice, this is how Lemmy is too. Most people are on Lemmy.world, and they picked that server because they don't think decentralized is important.

  • source
  • hideshow 2 child comments
  • [–] 9 points 2 years ago (1 child)

    Single Sign On doesn't mean that "American BigTech Servers" have to be used.

    Essentially, for the users, it means that an account for site A can be used to login on site B because site A and site B trust each other.

    A concept to Google if one wants to know more is "federated login".

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 2 years ago (1 child)

    Yea this is exactly what I was thinking about.

    The idea being that there would be circles of trusted platforms and once you have an account with one you have an account on all of them. Which, I imagine, would allow easy/quick cross posting from one platform to another when desired and make it easier to build and maintain an aggregating client that allows you to view all the platforms within such a "circle of trust" that you're interested in through a unified interface.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 2 years ago (3 children)

    @maegul How would servers share accounts and passwords? Allowing any server to know what a user’s password should be is not very good for security.

    @fediverse @maegul @1984 @mindlight

  • source
  • parent
  • hideshow 6 child comments
  • [–] 4 points 2 years ago (1 child)

    Trusting other peoples identification and authorizattion isnt about sharing accounts and passwords. If user A of server X want to log in at server Y, server Y asks server X if it knows this user A. If so server X handles the password/mfa check and just gives the green light to server Y.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 2 years ago (1 child)

    @Aatube @maegul@hachyderm.io @1984 @mindlight @maegul@lemmy.ml
    Couldn't it be like public-private keys such PGP protocols, where the users have the private key and the platforms have the public key? It's seems quite good privacy, some would even say it's "pretty good privacy".

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 years ago (1 child)

    @Sean Nice pun :D

    I don’t think requiring users to use a really long and virtually unmemorizable password (the private key) would be a pretty good idea for a social network either.

    @fediverse @maegul @1984 @mindlight @maegul

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 2 years ago (1 child)

    @Aatube @maegul@hachyderm.io @1984 @mindlight @maegul@lemmy.ml
    The private key doesn't need to be memorized, it stays saved on the device that the client software is on, allowing the user to integrate mobile device's biometric reader (fingerprint/face/iris/whatever) to confirm identity, or use security key, there are already different ways to implement it that doesn't require pw memorization.

    I've got a long unmemorizable string for Firefox sync, Brave, Proton Mail/Pass, it's still more secure than pw memorized

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 2 points 2 years ago (1 child)

    @Aatube @1984 @mindlight @maegul@lemmy.ml

    Yea I don’t know the best approach to that. Either a separate server for managing IDs. Or you always a principal server that manages authentication for its platform and others within the trusted “circle”. And then, should the principal server fail, you can switch to another server as your principal. Hubzilla/Streams has some process like that AFAIK.

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 1 point 2 years ago

    @Aatube @1984 @mindlight @maegul@lemmy.ml

    The key idea is that you can have a single unified identity on all the platforms you want. Signing into multiple platforms doesn’t require a new account every time. And cross posting from one platform to another, under your single identity is easy from every platform.

    Then leveraging those features (and an open API), a good unifying client will make that easy.

    There must be a way of doing that without fatal security issues or decentralisation.

  • source
  • parent
  • [–] 10 points 2 years ago (1 child)

    Sorry but I fail to understand the relation between your question and the additional text.

    Are the bulletpoints requirements for a less over-engineered attempt ?

    Or are they examples of the current situation?

    And just software without protocol seems. .... oversimplification.

  • source
  • hideshow 2 child comments
  • [–] [S] 1 point 2 years ago

    @joeldebruijn

    Quick attempt at coming up with an alternative.

    Something to bear in mind here is it’s my impression that federation creates difficulties that many struggle with. So while it might be over simplified, the scale for me is already weighed with the possibility that we over complication that may need to be remedied.

    Also, that big instances (eg mastodon.social) seem to be a natural thing even on the Fedi, there’s clearly perceived value for many there.

  • source
  • parent
  • [–] [S] 5 points 2 years ago

    @fediverse

    All of the shared/single sign on and easy cross posting would probably be trust or allow-list based.

    As the platforms would be FOSS, anyone could run their own instance and start their own "circles of trust". So even with big vs small server friction, there could be a few "gardens" of small and big server networks providing different "spaces" for different purposes ... all without having to worry about defederation and the software difficulties of building against the protocol.

  • source
  • [–] 3 points 2 years ago (1 child)

    Maybe good old blogosphere with comments pingbacks and pubsubhub(?) was a sort of simpler proto version of the fediverse.

  • source
  • hideshow 2 child comments
  • [–] [S] 0 points 2 years ago (2 children)

    @joeldebruijn

    Yep. Add a good aggregator client (hmmm, Google should make one) and you’re cooking.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 years ago (1 child)
  • [+] 1 point 2 years ago* (1 child)
  • [+] 1 point 2 years ago* (1 child)
  • [–] [S] 1 point 2 years ago (1 child)

    @strife @joeldebruijn

    Yea this is the essence of the idea. Strip down the interop requirements as much as possible, relying on existing tech as much as possible, and allow software and norms to solve all the other problems, where, TBF, it seems that software is doing all the heavy lifting in the fediverse anyway, but also has to handle federation and the protocol.

  • source
  • parent
  • hideshow 2 child comments