The open-source ones? I don't even remember nowadays, because they got squished under the XMPP juggernaut. I think there was one that was based off of Gadu-Gadu's protocol (may even have been basically the same protocol with just the servers switched out). But whenever someone tried to drum up support for a new open-source messenger it was always "Why not just use XMPP? It's the standard, and it's extensible, so I'm sure it can accommodate whatever features you were thinking of".
I honestly don’t remember ever using open protocols to chat, sorry.
Born in ‘97, I was too young for IRC’s height, and although I flirted with XMPP, none of my friends were there so it was just me and a handful of like-minded people I’ve met on the Internet. I think XMPP’s peak was when Facebook and Google supported it for a while, before erecting the walls.
Now there is Matrix which serves a similar niche (albeit more successfully) but doesn’t seem that interested in being a WhatsApp/iMessage replacement for casual day-to-day use. Discord and Telegram have a huge social network element to them but in my limited experience, the performance issues in the very protocol itself and/or with Element (the de-facto Matrix client) hinder its adoption.
Yeah, in 1997 I was using gaim to talk to anyone I wanted on AIM, ICQ, MSN etc and it worked great. But as the olds like me fade away nobody who remembers the open internet will be around to say what we lost :-(
> which would make migration between instances seamless.
Which instances? :)
If you're referring to "Personal Data Stores", sure. However, it's the "Relay" (i.e. the aggregator that generates timelines) that everyone relies on is centralized. In contrast, with Mastodon for example, both "Personal Data Store" and "Relay" functionalities are decentralised, offering a complete solution with no centralised choke-points. At least that's my non-authoritative understanding.
There is this lengthy blog post, _How decentralized is Bluesky really?_ [0], if you want to read more about the differences between Bluesky and ActivityPub (e.g. Mastodon).
> the federation of that massive amount of data and storage
I'm not sure what you mean by that but the media blobs (photos and videos) are not "federated" (i.e. passed around instances) most likely, but hosted in one place (the instance of the author) and referenced by their URL.
it varies by activitypub implementation. mastodon for example caches media per instance, pleroma simply hotlinks.
briefly searching through github issues, i believe pixelfed does not cache remote media. discussion on this issue about remote media cacheing seems to indicate that pixelfed only caches avatars https://github.com/pixelfed/pixelfed/issues/4571
Intuitively, it is unlikely there's 500K individual servers set up.
We can then also observe other comments clarifying that no, there aren't 500K instances.
The other comments provide...tweets? mastodons?...from the maintainer also clarify that in practice, there's 1 instance.
People are questioning how that will scale, and the tweet from the maintainer was cited as part of that because the content of the tweet is that tl;dr there's a $2,600 month gap between Patreon and hosting costs.
Alluded multiple times in the comments already but worth being explicit: Aaron Swartz killed himself 12 years ago yesterday for facing "a cumulative maximum penalty of $1 million in fines, 35 years in prison" [0] after downloading academic journal articles, which would be only a small percentage of what's available on LibGen.
Swartz was charged with 35 to 50 years, realistically faced up to 10, and was offered 6 months if he plead guilty [1]. That offer moreover wasn’t the final offer.
Put another way, it’s not clear that the law is being applied to Zuckerberg differently than it was to Swartz given the law wasn’t actually ever applied to Swartz. (Or that they wouldn’t gladly trade this lawbreaking for $1mm in fines and a negotiation over penalties where the prosecution opens with 6 months jail.)
The prosecutor acted inappropriately in that case; MIT, more wildly so. That doesn’t, however, carry over to a transgression of the law given we never got to that stage.
> Has Zuckerberg actually been charged with something with equivalent potential consequences?
I didn’t say Zuckerberg has been subjected to what Swartz was. Swartz never wielded the nation-state level power of a billionaire—it’s difficult to imagine how he could be subjected to similar psychological stress.
I said the law isn’t being applied to Zuckerberg (or anyone who has downloaded LibGen, for that matter) differently because the law was never applied to Swartz. Given the unpopular Swartz prosecution ended Ortiz’s career, and the lack of recent criminal copyright cases, it’s unlikely anyone would attempt to apply it as they did then. To anyone, including Zuckerberg.
TL; DR If you dislike what Zuckerberg is doing, you’re probably advocating for a clarification of the law. If you like it, erm, nothing much to do here.
> So there's a lot of DHT network scanning going on for sure.
There is an entire category of free software whose purpose is to create an index of the DHT network. :) The idea is to allow users to find and search for torrents in a completely decentralised manner (i.e. without relying on any centralised trackers or search engines).[1] A good example is bitmagnet[0].
My understanding is that IPFS always requires an IPFS → HTTP gateway to work in browsers, so I wonder what you mean by "P2P retrival in browsers".
Verified Fetch is about verifying content retrieved from gateways on client-side but the retrival is still very much client-server (vs P2P) today, and Service Worker Gateway seems to be relying on gateways too (<trustless-gateway.link> in the demo linked).
Based on IPFS & HTTP: The Blueprint for Radical Interoperability - Lidel [0], I believe the situation is acknowledged by IPFS devs too. In my unsolicited opinion, using a custom protocol (libp2p transports?) for a project targetting web browsers was a mistake, so I'm glad to see that HTTP is being considered now.
> My understanding is that IPFS always requires an IPFS → HTTP gateway to work in browsers, so I wonder what you mean by "P2P retrival in browsers".
By P2P retrieval, I mean retrieval directly from a peer that has the data without additional hops.
Historically HTTP gateways were the only way, because you couldn't dial (most) peers directly from a browser unless they had a CA-signed TLS certificate (needed in secure contexts.)
A couple of things changed that:
- WebTransport and WebRTC-direct allow browser-server(peer) communication without a CA signed certificate. WebTransport is very new and still has some problems in browser implementations.
- We just launched AutoTLS which help public IPFS node get a wildcard let's encrypt TLS certificate, making it "dialable" from browsers
With these, it becomes a whole lot easier to establish connections from browsers to IPFS nodes. But it takes time for the network to upgrade.
Note that Libp2p transports are wrappers over network transports to allow interoperability across runtimes, e.g. TCP, QUIC, WebSockets, WebTransport. These are not custom protocols.
Now you point about custom protocols, by which I presume you are referring to data exchange/retrieval protocols.
There are two IPFS data transfer protocols:
- Bitswap: the first and default data transfer protocol which requires a streaming network transport (so HTTP isn't ideal).
- HTTP Gateways: Initially, HTTP gateways were servers that would handle retrieval (over Bitswap) for you if they didn't have the data locally (sometimes we refer to these as Recursive Gateways, like trustless-gateway.link and ipfs.io). For all the reasons in Lidel's talk (caching, interop, composability), we extended this notion and made HTTP Gateway a general interface for data retrieval.
Today, there are large providers in the network (pinning services) that expose their data with an HTTP Gateway, which allows browsers to retrieve from directly.
We still have more work to do to expose the gateway in Kubo with the new AutoTLS certificate, but for the time being, Bitswap should work well enough even in browsers over a WebSockets connection.
---
Verified Fetch's aims to ensure you get data is it's available. If it fails to find a direct provider of the data, it will fall back on a recursive gateway like trustless-gateway.link which is configured in the defaults. As more IPFS nodes upgrade to newer versions, reliance on such centralised recursive gateways will become unnecessary.
TL;DR: We're all in on HTTP. The real constraint to P2P is browser vendors and slow standard bodies.
