At present, I think most implementations are based on Node.js.
An important thing in SSB is "Pubs". The link above says this:
> "Pubs" are bot-users that have public IPs. They follow users and rehost the messages to other peers, ensuring good uptime and no firewall blockage.
> Pubs have no special privileges, and are not trusted by users. However, because Scuttlebot has no DHT or NAT-traversal utilities, users must "join" a Pub to distribute their messages on the WAN.
Without a lot of active experience with SSB or its clients, it seems that pubs are a weak point and a centralizing influence. Sure, I could host a pub myself, but then I'd need to attract a good sized fraction of the overall SSB userbase, so that those connecting to my pub could find interesting users.
I'll wait another week or two before I completely abandon it.
I should write up my experience with the #SSB network. I'd heard so much about this wonder of #DCO (disconnected operation) and #P2P (peer-to-peer) that I think my expectations were too high.
I'm not very conversational there. I pretty much just read others' posts. I rarely respond or post.
#SSB seems to be a "refrigerator magnet" type of place.
Let me explain that term. When #GD2 sends me some of her artwork, I stick one piece up on the fridge (using a magnet). That's "Look at what [my granddaughter] drew / colored / painted for me". So "refrigerator magnet" is hey, look at what I did.
Copying a 'pub' invite and pasting it into the client is not easy. It took several tries on the Apple iPad, and was only possible by learning to trick the text selection function. On Android, there are some characters in the pub invite that can only be selected if you select all (grabs way more than what you want, leaving you to edit after pasting). I eventually resorted to copying the portion that selected easily, and manually entering the rest.
Each device / installation gets its own individual identity hash. In your profile, you can attach a friendly name, which is displayed to others instead of the full identity hash. Don't try restoring a hash from one device onto another, because the #Secure_Scuttlebutt network seems to deliver everything to the first device and leave the second one alone.
There seems to be a smallish set of users, many of whom are building SSB software, hosting pubs, and building similar #peer-to-peer ( #p2p ) networks.
I am nowhere near an expert with it, and I generally only open the client about once per week. It usually takes a while to update, so at first, the old posts from a week before are all you see.
I’ll have to read more about #Secure_Scuttlebutt to see whether #SSB is meant to allow the same userID across multiple devices. If I get a contact or join a ‘pub’ on one device, is that connection also available on the other?
> An e-mail _server_, OStatus _server_, XMPP _server_ etc. need to be available _all the time_, or near enough to make no difference.
That is only true because of how the protocols work.
#ssb is designed to handle intermittent connections and drop points. There is no global blockchain. There is an issue of how much to replicate and how much to miss out on, and pubs are doing maybe a bit too much work, but those things are being worked on as well, improving granularity along various axes.
For IM, sure, if you want to send offline messages your peers need to be online at the same time at some point, but for people you usually have synchronous conversations with, this isn't a big issue.
> Just as Systematic Colonization was developed to establish the capitalist mode of production in the colonies, anti-disintermediation was [developed] to colonize cyberspace. The basic strategy of anti-disintermediation was formulated by economists like Carl Shapiro and Hal R. Varian. Their influential book Information Rules encourages platform owners to pursue "lock-in." As Varian explains, "Since information technology products work in systems, switching any single product can cost users dearly. The lock-in that results from such switching costs confers a huge competitive advantage to firms that manage their installed base of customers effectively."
[ . . . ]
> Central to the counter-anti-disintermediationist design is the End-to-End principle: platforms must not depend on servers and admins, even when cooperatively run, but must, to the greatest degree possible, run on the computers of the platform’s users. The computational capacity and network access of the users’ own computers must collectively make up the resources of the platform, such that, on average, each new user adds net resources to the platform. By keeping the computational capacity in the hands of the users, we prevent the communication platform from becoming capital, and we prevent the users from being instrumentalized as an audience commodity.
TL;DR: Kill the server-web as the backbone of personal communications.