I’m genuinely interested in people thoughts about the Fediverse because here in the UK it has massively stalled in 2025, like a lot of things. I am seeing way less posts from UK people and way less interaction and general use in fact. Most seem to have stopped social media use to be fair, and I know a lot of that is to do with my age (old fart here, 56 laps round sun and counting) but the numbers game look poor from my point of view. Do we think the Fediverse has a future now after useage appears to be going downwards? Is it a UK thing? (well I know the UK is weird but hey)

  • 🇦🇺𝕄𝕦𝕟𝕥𝕖𝕕𝕔𝕣𝕠𝕔𝕠𝕕𝕚𝕝𝕖@hilariouschaos.comEnglish
    11·
    3 days ago

    Oidc is the protocol by which auth can happen its the evolution of oauth. U need to build some kind of decentralised ledger then u set up a server that checks that ledger against the user provided auth then u simply make this server have an oidc endpoint allowing it to be plug and play with existing fediverse services.

    I say oidc cos almost all fediverse software is already compatible with it.

    • rglullis@communick.newsEnglish
      1·
      3 days ago

      My point is: if you have a ledger that the user controls and can use to redirect to different auth endpoints, then you don’t need oauth. You just use the record in the ledger as the authentication mechanism directly.

      • 🇦🇺𝕄𝕦𝕟𝕥𝕖𝕕𝕔𝕣𝕠𝕔𝕠𝕕𝕚𝕝𝕖@hilariouschaos.comEnglish
        11·
        3 days ago

        Yeah exactly. But instead of having to implement that auth process in every different fediverse service in however many different languages u simply write it once with an oidc endpoint and all fediverse services can run it as a container in their stack. It makes implementing such auth system a simple config change and updating a docker compose to add a new service.

        • rglullis@communick.newsEnglish
          1·
          3 days ago

          It looks like we are talking past one-another.

          What I am trying to say is that “getting the user to complete a login” is not the novel part that is missing. What we are missing is a way for the user to have control over their actor ID, so that they use the same id regardless of what server that id is delegated to.

          So, unless I am misunderstanding you, what you are proposing is an OIDC provider which could be used to authenticate on any other service. That’s good, but it doesn’t solve the problem that if we had an unified OIDC provider without a DID, all of the actor ids would end up dependent on the OIDC provider.