Conversation

Notices

1. Embed this notice
   Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 01:42:42 JST Hyolobrika

   • Taylan (Now 18% More Deranged)
   You mean @taylankammer.bsky.social?
   
   BTW, have you heard of Nostr?
   BSky is pretty centralised, I've heard.
   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 01:42:31 JST Hyolobrika

     in reply to

     • arcanicanis
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     What about Nostr relays? They’re visible if you look at your list.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 13-Feb-2024 01:42:31 JST silverpill

     in reply to

     • arcanicanis
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     @Hyolobrika @arcanicanis @adiz But the list is hidden somewhere in the settings, right? The majority of users will use hosted clients and never bother with relay management.

     This is a well-known failure mode of web3 protocols: underlying infrastructure gets abstracted away and people flock to the most feature-rich client. I know Alex is trying to fix that, but I don't think his solution will be popular.

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Tuesday, 13-Feb-2024 01:42:33 JST arcanicanis

     in reply to

     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     The reason I think ‘federated’ has much more practicality, is because it’s far easier to conceptualize, establish responsibility of who pays the bills for running the servers, easier to locate a resource (if it uses some conventional identifier, like a URL), etc.

     Whereas with “truly decentralized mesh, everything is a node, no distinction of client/server”: usually some entity still has to pick up the slack and host high-bandwidth/high-uptime nodes, or seed a sizable portion of the network (if storage focused), or centrally run some ‘jumpstart’ servers (to be a new node’s first peer, to discover the rest of the network to peer with) for the network, entirely as some cash-furnace charity.

     As it is with Tor, I have no idea where it’d be if it was without a few of it’s top exit node providers, since there’s virtually no incentive to ever host an exit node: https://metrics.torproject.org/bubbles.html#as-exits-only

     The only model that I think anything ‘truly decentralized’ would be self-sustaining is if it involves some autonomous cryptocurrency-based concept, but that also adds more cost and overhead (including blockchain, consensus, etc), and I assume also difficult to design a system that provably measures resource costs (such as rewarding someone for hosting a resource, providing bandwidth, etc).

     It feels like everyone always tiers the concepts strictly into (from worst to inherently best): centralized, federated, decentralized mesh; always striving decentralized mesh as ‘the Holy Grail’, always better above-all. It’s seldom viewed instead where there’s tradeoffs between federated and decentralized.

     Also instead of having to combine decentralization all into one application protocol, sometimes it’s better just being left as an external responsibility of an underlying network; in other words, just take what we already have, and combine them together: host a single-user fedi instance on Tor, I2P, or some other overlay encrypted meshnet, and you get some of the bonuses without having to invent a whole new protocol and whole new suite of cross-platform client/node software (which can take YEARS to iron out).

   • Embed this notice
     :verified_2:防空識別區𝒔𝒐𝒄𝟶 (adiz@soc0.outrnat.nl)'s status on Tuesday, 13-Feb-2024 01:42:34 JST :verified_2:防空識別區𝒔𝒐𝒄𝟶

     in reply to

     @Hyolobrika@social.fbxl.net Oh, this is a cool document. Thanks for sharing it. I'm really interested in SSB as an alternative to things like the Fediverse. The Fediverse, in my opinion, has the best model for a decentralized, federated network from a client-server-client standpoint. The next frontier would be directly peer-to-peer, and SSB, while imperfect, has the best idea therein.

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 01:42:35 JST Hyolobrika

     in reply to

     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     BTW, here's a PDF someone sent me (haven't read yet)
     https://bsky.social/about/bluesky-and-the-at-protocol-usable-decentralized-social-media-martin-kleppmann.pdf
   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 01:42:36 JST Hyolobrika

     in reply to

     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     Where did they say that?
   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 01:42:37 JST Hyolobrika

     in reply to

     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     How are the relays controlled?
   • Embed this notice
     :verified_2:防空識別區𝒔𝒐𝒄𝟶 (adiz@soc0.outrnat.nl)'s status on Tuesday, 13-Feb-2024 01:42:37 JST :verified_2:防空識別區𝒔𝒐𝒄𝟶

     in reply to

     @Hyolobrika@social.fbxl.net BlueSky team previously discussed only allowing "trusted" entities to operate relays for the network or something. They had been referring to these in their earlier papers as "trusted nodes" instead of "relays" and heavily suggested that it would be like an invite-only thing.

   • Embed this notice
     :verified_2:防空識別區𝒔𝒐𝒄𝟶 (adiz@soc0.outrnat.nl)'s status on Tuesday, 13-Feb-2024 01:42:39 JST :verified_2:防空識別區𝒔𝒐𝒄𝟶

     in reply to

     @Hyolobrika@social.fbxl.net The identity layer is centralized and the relays are controlled. There are currently not PDSs available, afaIk, nor any infrastructure available for any/to facilitate any. I.e., these implementations are still a WIP or hypothetical facet of the theoretical system at scale.

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 01:42:40 JST Hyolobrika

     in reply to

     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     What I heard was that there can be third-party "PDSs" but the identity layer (did:plc) is centralised.
     https://bsky.social/about/blog/5-5-2023-federation-architecture
   • Embed this notice
     :verified_2:防空識別區𝒔𝒐𝒄𝟶 (adiz@soc0.outrnat.nl)'s status on Tuesday, 13-Feb-2024 01:42:41 JST :verified_2:防空識別區𝒔𝒐𝒄𝟶

     in reply to

     @Hyolobrika@social.fbxl.net BlueSky isn't "pretty centralized", it's just centralized, straight-up. There are no other servers, there is only the BlueSky server. There is not even server software or code or documentation yet available for people to theoretically create their own server and federate. The "decentralization" claims come with a bunch of asterisks that should say: hypothetically one day maybe we'll think about it

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 13-Feb-2024 03:17:21 JST silverpill

     in reply to

     • arcanicanis
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     @Hyolobrika @arcanicanis @adiz By introducing "instances"

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 03:17:22 JST Hyolobrika

     in reply to

     • arcanicanis
     • silverpill
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     How is he trying to fix it?
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 13-Feb-2024 03:22:17 JST silverpill

     in reply to

     • arcanicanis
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     @arcanicanis @Hyolobrika @adiz I don't know if he has a design doc. Damned Gitlab is not working for me https://gitlab.com/soapbox-pub/ditto

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 13-Feb-2024 03:44:56 JST silverpill

     in reply to

     • arcanicanis
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     @Hyolobrika @arcanicanis @adiz This term is not used in Nostr land, as far as know. But I think he wants Ditto installations to look like fedi instances, yes

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 03:45:02 JST Hyolobrika

     in reply to

     • arcanicanis
     • silverpill
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     Why the scare quotes? How are these instances not like normal instances?
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 13-Feb-2024 05:27:15 JST silverpill

     in reply to

     • Alex Gleason
     • arcanicanis
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶

     @Hyolobrika @arcanicanis @adiz Yes, this is one of the stated goals, but I think it is primarily a social media server, not a bridge. It is better than average fedi software because the data is portable. Anyway, no need to speculate here, surely @alex can clarify the purpose of this project

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 05:27:16 JST Hyolobrika

     in reply to

     • arcanicanis
     • silverpill
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     I had always thought Ditto was about making Nostr and fedi play nicely together.
   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 13-Feb-2024 05:27:17 JST Hyolobrika

     in reply to

     • arcanicanis
     • silverpill
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     How is this better than fedi and Nostr then?
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 13-Feb-2024 07:11:58 JST Alex Gleason

     in reply to

     • arcanicanis
     • silverpill
     • :verified_2:防空識別區𝒔𝒐𝒄𝟶
     @silverpill @Hyolobrika @adiz @arcanicanis I'm figuring it out as I build it. It's "instances on Nostr", yes. But it's also where I'll build new social media features going forward. I have a couple exciting ideas bottled up until the main functionality works.