https://www.bitchute.com/video/EzUKGI9cyQHY/
THE #PROTOCOLS OF THE LEARNED ELDERS WHO GOVERN YOU

Bluesky vs. Nostr vs. ActivityPub — Which Should Developers Care About More?

Yes, there is quite a debate raging across different networks about what protocol to support. Obviously, those who know only one well, are going to root for that one, irrespective of whether it may be the best one.

From a dev perspective, where do you throw your efforts in from a perspective of the future growth of the protocol, and how flexible and free is that protocol going to be to new ideas and advancements. The “best” protocol also does not necessarily mean it will be the most successful, or the most adopted one, as we’ve seen all sorts of politics, misinformation, bad PR, etc play a role in the past (just see what happened to the Zot protocol which has nomadic ID).

From a user perspective, what network do you join and put all your creativity efforts into?

There is no easy answer, and some have even suggested, to get away from the entrenched positions, why not create a brand new protocol! But that has actually happened repeatedly already, and none ever took the “ring that would rule all rings”. Client apps like Hubzilla and Friendica, of course, took the approach rather to support multiple protocols so that your one app connects across different networks. Maybe there is still something in that idea.

The Bluesky protocol may well be loosened up in future, and although ActivityPub is quite open (not owned by anyone), it is still actually quite limited in terms of not having profile migrations, groups, and other features. So yes, Nostr right now is probably the most open with devs registering NIPs (Nostr Implementation Possibilities), much like we also see with XMPP protocol’s XEPs. It all comes down then, to what NIPs a particular client supports.

Personally, as a user, I still long for a fully interoperable protocol, one for instant messaging, as well as for social networking (or combined into one). Look at e-mail. It may be very dated, but it made no difference which service your joined (apart from the domain name you got) and it always connected to other e-mail clients, and it is not owned by any one company or central server.

But whilst we have this situation, I’m wondering if we won’t see the emergence of some future “translation protocol” that will allow posts from XMPP to translate into ActivityPub, Bluesky, Nostr, etc, and go the other way too?

I do think users, at least, are starting to accept the situation of social networks going decentralised and federated, and are realising it is not so complicated to grasp. We’ve been spoilt and brainwashed too long by strong authoritarian centralised network services. If we don’t demand more open and interoperable social networks now, we are doomed to repeat the lock-ins of Twitter, Facebook, etc all over again. Then our friends can be on any network, and we can still interact fully with each other, like we’ve been doing with e-mail.

See https://thenewstack.io/bluesky-vs-nostr-which-should-developers-care-about-more/
#Blog, #interoperability, #openstandards, #protocols, #socialnetworks, #technology

The Three-Legged Stool: A Manifesto for a Smaller, Denser Internet

Thanks to Cory for the link.

https://publicinfrastructure.org/2023/03/29/the-three-legged-stool/

1. Consists of many different platforms with a wide variety of scales and purposes;
2. Users can navigate with a loyal client that aggregates, cross-posts, and curates;
3. Is all supported by cross-cutting services rooted in interoperable data.

First, we propose a pluriverse consisting of existing platforms alongside a flourishing ecosystem of Very Small Online Platforms (VSOPs) that serve conversations and communities that are poorly served by today’s digital public sphere. Just as we do not exclusively gather in shopping malls in the physical world, Facebook, Twitter, and YouTube are not the right place for every community and conversation online. We argue the need for civic-centered VSOPs like our platform Smalltown. We highlight existing VSOPs like Letterboxd and An Archive of Our Own and discuss what it takes to develop a new VSOP, using our work on Freq, a VSOP dedicated to music discovery and discussion, as a case study.\
\
Second, we sketch out a “loyal client” for navigating the digital public sphere. Akin to an email client like Apple Mail or a chat client like ICQ, our loyal client aggregates, filters, and posts to a person’s various social media feeds, be those VSOPs or established platforms like Twitter or Reddit. Such a tool depends on people being able to delegate authority to a loyal client, which comes with challenges related to privacy, adoption, and usability.\
\
Third, we introduce the “friendly neighborhood algorithm store.” This is a marketplace that VSOPs and loyal clients can rely on for curation and Trust & Safety, tools which no single VSOP or loyal client could develop on their own, and which large platforms have developed over decades with significant resources. These include recommender systems, spam detection, anti-abuse tools, and powerful filters for CSAM and terrorist content.

PDF https://publicinfrastructure.org/wp-content/uploads/2023/03/The-Three-Legged-Stool-by-Chand-Rajendra-Nicolucci-Michael-Sugarman-and-Ethan-Zuckerman-iDPI-UMass.pdf
HTML https://drive.google.com/file/d/1ral-dsAcl_CjY0QZrELq4yWigq4rT3UB/view

I think it's important that alternative webs be simple at the protocol level so that many, many developers can reasonably quickly develop their own client and server software. Also, complexity is the enemy of security.

#internet #platforms #protocols #social-networks

The Internet just changed. What this is about is a protocol called QUIC, that is in essence a replacement for TCP. This video does an impressive job of distilling knowledge from dry RFCs into something us mere mortals can understand. The underlying protocol of the internet is IP, which stands for Internet Protocol. It basically deals with moving a packet of information from one place to another. And that's all it does. It doesn't have any concept of a "connection", and any notion of reliability, i.e. if a packet gets lost, IP doesn't notice. That's why TCP, which stands for Transmission Control Protocol, was invented. It creates the concept of "connections", it gives packets "sequence numbers", it notices when packets arrive out of order and rearranges them, and if they don't arrive at all in which case it will request they get retransmitted. It is the TCP protocol that QUIC aims to replace.

But since TCP is embedded deeply in operating system kernels, replacing it with anything else would be hard. But alongside TCP, the makers of IP also made a parallel networking service called UDP, which stands for User Datagram Protocol. It is almost IP packets and nothing else. Well, there is a little more -- UDP provides checksums to detect errors and it also has the TCP concept of port numbers. But that's it. It has no concept of connections. With QUIC, they figured out how to invent a new TCP replacement by building it on UDP. In fact QUIC stands for Quick UDP Internet Connections.

But first, we have to ask, why would anyone want to replace TCP? It turns out that engineers since the invention of TCP have figured out how to make the "handshake" process more efficient. The "handshake" is the initial back-and-fourth process that enables the two sides to set up a connection between each other. Not only that, but immediately after a browser sets up a TCP connection, it has to do another handshake to set up the encryption, so the communication connection is secure. The protocol to do this is called TLS, which stands for Transport Layer Security. What the inventors of QUIC figured out how to do is do both the connection handshake and the encryption handshake simultaneously, and efficiently. In practice this means when you connect to a website, you get the first part of your webpage faster (what in computer science parlance is called lower latency).

QUIC doesn't stop there. With regular TCP connections, missing packets can cause one side or the other to wait while retransmission is requested and packets arriving out of order get properly resequenced. QUIC is smart enough to know when packets are interdependent and when they're not. So for example it can figure out it's got all the packets for an image so the browser can go ahead and display the image to you, but it doesn't have all the packets for the JavaScript so it can't run the JavaScript yet.

QUIC was invented by Google and has already been deployed in the Chrome browser, so if you're using Chrome, you're using it already. Microsoft Edge and Firefox already support it. On the server side, not just Google but many other major companies like Facebook (er, Meta), have already rolled it out. This was all possible because it's able to run on UDP and doesn't require operating systems to be upgraded to upgrade TCP.

The only downside is that many routers and firewalls block UDP completely for security reasons. But even here, rather than have to have everyone buy new routers and firewalls, it's possible to enable it by changing the settings on existing routers and firewalls. It will take time for security professionals to make this change, and some will never do it because the higher encryption level of QUIC means it's harder to tell what traffic is going through a router or firewall, and some people will never be comfortable allowing traffic they can't see. That's why browsers have to have the ability to fall back to regular TCP.

The Internet just changed. - David Bombal

#networking #internet #protocols #tcpip

How to design an anti-monopoly interoperability system

"A historical accident made Massachusetts a lab for studying how tech can serve monopolies, and the moves, countermoves and counter-countermoves show how businesses, tinkerers, governments and the public can liberate themselves from seemingly all-powerful monopolists."

How to design an anti-monopoly interoperability system
https://pluralistic.net/2022/02/05/time-for-some-game-theory/#massholes

#monopoly #monopolies #tech #technology #computers #software #internet #BigTech #GAFAM #Google #Apple #Facebook #Amazon #Microsoft #Meta #AntiMonopoly #AntiTrust #interoperability #privacy #competition #policy #law #RightToRepair #DRM #DigitalRestrictionsmanagement #OpenSource #FreeSoftware #standards #protocols #OpenStandards #OpenFormats #DigitalMarketsAct #DMA

this is a russian podcast on history of the fediverse: https://open.tube/videos/watch/db9cc76d-093c-4347-a49a-9af4246a1d92

i have to say they did a comprehensive research, or did know the history very well.
it starts with the early internet, email, then explains situation with messengers, xmpp, xml, rss, tells about aaron schwartz, and goes in to early fediverse projects, starting from identica.

in this podcast, diaspora is a tragic story. near the end of the podcast they mention the ticket to support activitypub, and that the comments were mostly not about whether it should be done, but on how it should be done. and then comes dennis schubert, critisizes the protocol and rejects the wanted proposal. then they say that diaspora is getting weaker - quantity of nodes decreases, while fediverse is getting richer - more and more people are attracted.

mastodon was mentioned as a huge success. well, it is a huge success. but they also mentioned that the project is heavy, slow, not easily deployed, has too many dependencies. most of that can also be said about diaspora. the pleroma was presented as an alternative, which is much faster, easily updated without downtime, thanks to underlying erlang ecosystem. it also supports gopher!

i did not think socialhome will be mentioned. but jason robinson was mentioned several times, as federation activist, diaspora developer, then the-federation.info author, and then they described the socialhome project in details, starting with its history. mentioned that it has very little number of nodes, and expressed the hope that it'll be developed further.

they also were talking about pixelfed, funkwhale, peertube, mobilizon, and the blog engines that support federation: write freely, plume, and that wordpress is able to federate with activitypub nodes via special plugin.

overall, very interesting, for me, listening, and a very good introduction for newcomers. thanks to creators. i am really thankful to creators, i wish the text was published, because i know many prefer to read, not listen, like me, also it would make the text searchable.

#russian #podcast #history #internet #diaspora #mastodon #decentralization #socialhome #pixelfed #funkwhale #peertube #mobilizon, #blog #rss #atom #writefreely #plume #wordpress #activitypub #federation #freedom #freedom_of_speech #freedom-of-speech #freedomofspeech #web #gopher #w3c #standards #protocol #protocols #research #listening

Morning Ramble: Personal media strategies and protocols

John Wehrle suggests at The Beginning is Near that it might be possible to split Google+ activity into separate activities using multiple tools. This is very much what I've been thinking, with the key requirement that the tools interoperate, and if possible interact.

What I foresee myself doing:

1. Write, blog, research, organise, and Wiki: GitLab, using a static-site generator, and finding some way to support search (a critical function) and if possible at least some commenting capacity. In this case, my source content is directly in my control, under git, on my own desktop, in backups, and at any other hosts I syndicate that to.

2. Direct syndication through RSS/Atom. Feedreaders and other systems can access / consume this. It's not widely used these days, but is the basis for basic syndication and other capabilities.

3. Propagation through microblogging platform(s). Mastodon certainly. I may even set up a Twitter account. I'm considering the username "Registered under protest" preliminarily.... (There's already a "dredmorbius", it's not me.)

4. Further propagation through social / lightweight blogging networks. Diaspora, Fediverse, Hubzilla, Friendica, etc.

Most of 3 & 4 would be automated.

1. Interaction and engagement on a personal basis (largely replacing G+) through one of the federated social networks. If I can have a central management hub for those (and I've run across a platform that seems to offer that on a web-based basis, though I'd prefer a local desktop or command-line option), so much the better. The faster I can slice through mentions, comments, etc. the better.\ \ One thing I've ... somewhat ... liked about G+ is that on desktop it's modestly possible to address interactions directly through the Notifications pane. Considering Notifications as its own stream and giving a way to rapidly:
   1. See events.
   2. Filter by type.
   3. Respond immedately from the Notifications context (screen, pane, pop-up, whatevs, though I prefer a page rather than overlay).
   4. Expand context in the Notifications context as needed for more complex stuff.
   5. Dismiss immediately events of no interest. (With an undo for fumbling finger factor.)
   6. Where any administrative factors are presented, say, group management or moderator actions -- approving, banning, admonishing, etc., users or content -- those controls are also presented directly in the Notifications context.

(The lack of this is a major frustration on Reddit. It's pathologically bad for G+ Communities, do not even get me started.)

I think that's a big chunk of it.

Notifications are a key and underappreciated element in social engagement

If you want to engage with others, you have to be aware of what it is that they are doing. And in the unlikely event that there might possibly be any among the 7.3 billions of souls in this world you don't care to interact with, not being principally aware of what they're doing may prove helpful.

(Not being principally aware does not necessitate being unaware, as with a full block. Though that is frequently how the capability is implemented.)

A lightweight Notifs management as a secondary option could also be useful.

A gripe I have with Diaspora is that dealing with Notifs is slow. It's only a few seconds' lag, but that's seconds that don't have to be there. A <300ms target would be ideal. I'm getting ~3s, which is 10x worse, and which repeated 33 times (present notifs count) is three minutes spent just waiting for things to happen while I'm responding to Notifications. And in cases that bumps up 2-3x slower, or worse. Nine minutes of wait. And 33 notifs is light traffic, at least right now.

The models I'm thinking of are G+, Diaspora, Ello (which has had several variations of Notifications, and created then reverted the best I've ever seen, sort of a side-pane, Usenet reader (think Netscape's Usenet client, or rtin), Reddit, and Hacker News (great on everything except context, though limited to replies only). Mutt (console email client) is among the best interfaces I've ever seen, and some sort of local social-to-email gateway might address a few concerns / considerations.

Speaking of email and Usenet: among many factors which killed them (and there were many -- see "Why Usnet Died" at the Dreddit) was the fact that there was no standardisation of composing conventions. You had a few schools of this, but they interacted poorly:

1. Top vs. bottom posting. Largely a Unix / Windows split.
2. Indication of emphasis, with the underscore/star style in plain text (similar to AsciiDoc). Markdown actually breaks a few of these conventions but is ubiquitous enough to be useful.
3. HTML vs. raw text.
4. Line length. Still matters for some.
5. Attachments.
6. Other rich-text formats.

(I've discussed this in the past month or so with Matthew Graybosh on Mastodon as well, if that discussion is discoverable. I'm ... not finding it presently.)

Among the fundamental failures was a failure to come to a common agreement on interactions. I had a revelation when reading about Docker, a lightweight virtualisation system. The technology consists solely of an agreement on how to do things. All the pieces were already there.

Incidentally, many of the problems with email also plague Web content. Sites are maddeningly inconsistent and idiosyncratic in their use of HTML, document structure (DOM), CSS, style, metadata, JavaScript, external dependencies, and more. I'm highly aware of this both given my dislike of most online styling (I have a large local CSS library applied to fix sites) and in trying to create a useful research archive of >10,000 articles from various sources. "Pocket: it gets worse the more you use it" is one of several critiques I've written of this, and there may be a project to address the useful utilisation of the Web as a research and collaboration platform. You know, as it was intended to be.

Protocols and standardisation, like trust, are social glue.

They can also create problems. Protocols that become change-resistant stagnate development. There are examples of this and the communications and information fields are rife with these because standards and conventions of exchange are the essence of communications. Lewis Carroll and the White Rabbit's "Glory" are the antithesis of communication -- if you use symbols known only to yourself, you can communicate with no one.

(Groups, though, using conventions known only internally, create the capacity to operate independently of an outside environment. This is a tool, for good or bad. See RibbonFarm's essay on "legibility vs. illegibility.)

SMTP, NNTP, IRC, SMS, HTML, nroff/groff, DocBook, Markdown, LaTeX (an extension of TeX), proprietary office formats (consider in context of above parenthetical note), RSS, Atom, XHTML, HTML5, the Federation / Fediverse protocols, Mastodon, diff formats, revision control formats, git, SSH, PGP, MIME, TCP/IP, Slack. They're all (at least in part) protocols, some open, some closed, some dynamic and developing, some static, some interacting, some not, some encapsulating, some encapsulated.

(Programming languages and various other bits overlap with this in various ways.)

OK, that's enough for this morning's ramble.

#googleplus #plusrefugees #protocols #MorningRamble #longForm #plexodus