The problem is also that federated doesn't really solve the problem of decentralization and that's the problem we ought to be solving. I don't want to create an account on the X instance of the fediverse, I want to create an account on the fediverse. It should be one big fediverse, which instance I use should be completely transparent and irrelevant. Coupling accounts to instances of the federation might be the easy solution, but it doesn't solve the problem we actually should be solving. This was already something I disliked about Jabber/XMPP and this was 20 years ago, we ought to have solved this by now.
What really grinds my gears is that all of the signup pages and “how to join” pages just say to pick a random instance because it’s federated and it doesn’t matter which one you join.<p>What if the random one I pick gets defederated? Now I need to find a new instance and make a new account?<p>This will make federated services into even MORE echo chamber ultra-moderated spaces than Reddit ever was, as the fear of defederation will cause lockdown policing of wrongthink.<p>I honestly think it may be worse for free speech.<p>Then again, I’ve never joined a federated service and I have no actual anecdote or evidence to back myself up, I’m kind of just spitballing thoughts.
> But this model breaks down because it wasn't designed under the premise that interactive applications would then be built on top of individual websites<p>Heh I was just reading "The Innovators" by Walter Issacson and found this interesting conflict between the inventor of the WWW and the inventor of Mosaic:<p>> There was something about Andreessen's browser (Mosaic), however, that disappointed Berners-Lee. It enabled rich media for publishing eye-catching pages, but that came at the expense of making it easy for making normal users to be able to write as well as read web pages. With Berners-Lee's browser, any user could edit web pages just as easily as reading them, just like using a word processor. But users of Andreessen's browser had to write the HTML code themselves and upload it. Berners-Lee feared that this might limit the ability to express themselves on the web to those who were technically astute.
Phony "federated apps" are mostly "fragile self-hosted with linkrot, convenience, and pseudo robustness".<p>Robust federation works as a distributed overlay network and doesn't require any leader. The irreducible issues become:<p>0. "Which systems should store what data, i.e., blobs (files), entities, and entity sequences?"<p>1. "How many copies should there be of 0.)?"<p>(1.5. "What will keep scrubbing 0.) for integrity and duplicating 1.) below a given threshold?")<p>2. "Where should functions against 0.-1. run?" #<p>3. "How many copies of 2.) should execute?" #<p>4. "How should the operators of persistent systems recoup the microtransactional costs of compute, storage, and networking of 0.-4.)?" (Client has a pool of credits purchased through some crypto means used to rent storage capacity, net transit, and processing of media, metadata, and code #.)<p>5. "How many copies of next nodes and node paths do you maintain?"<p>6. "Which nodes should this node remain connected to?"<p>7. "How many fixed default nodes can be run around the world to always seed a node's initial network topology?"<p>8. "How much anti-correlation traffic should fill the encrypted link when there is no traffic?" (Otherwise, it becomes very easy to poison and unmask overlay networks.)<p># If the platform has a serverless function concept, where it's unknown where it will run until it does.
I think the main problem is the cognitive and the technical overhead. Most users just want to use the site, they don't care about the underlying infrastructure. Federated services always have a cognitive overhead (where do I register? who do I follow) which centralised services don't have.<p>The real solution would be a regular, centralised service run by a non-profit.
I don’t understand the problem. The Fediverse already solved this. I can log into my Lemmy instance from any Lemmy app, same with Mastodon. There are also PWAs that do this.<p>Yes, I can’t log in from another instance’s website/frontend, but does it really matter?<p>The real problem is that my identity/account is coupled to the instance. If the instance disappears, so does my account and I lose everything.
Matrix tries to solve this with matrix.to (<a href="https://github.com/matrix-org/matrix.to">https://github.com/matrix-org/matrix.to</a>), which will eventually hopefully segue into a separate matrix:// protocol in URIs.
I think we could support decentralized protocols like IPFS or Freenet 2.0 at the browser level. Or even perhaps build in some type of UDP that could be easily enabled or a separate download.<p>I assume these ideas are blocked partly because companies like Google that have influence over browser features very much do not want a decentralized web.<p>Tying web pages to specific servers is also maybe something that deep down people won't or can't accept or understand about changing.<p>Maybe part of it is that it's hard to make p2p protocols work well and so people just aren't willing to try to tackle that and the challenge of getting that technology into browsers at the same time.
This is where content addressable URIs shine. IPFS is still pretty rough around the edges to use, but it allows hosting and distributing assets on the web without them being tied to a central server operator.
I agree with almost every comment in this thread, except that few seem to appreciate that "It should be one big fediverse, which instance I use should be completely transparent and irrelevant." is impossible without decentralized permissionless consensus: yes, blockchains. This is the thing they've been calling "web3", as much as HN seems to hate it.<p>web1 -> peer-to-peer decentralized networks without built-in consensus or economics; end up de facto centralized; SMTP, Nostr, RSS, etc.<p>web2 -> corporate owned networks; from iMessage to Tiktok to Reddit, this is most major networks today<p>web3 -> networks whose decentralization is enforced by cryptography and economics; Ethereum being one such example of a programmable network/computer<p>If you don't have cryptographic and economic mechanisms to encourage decentralization and resist centralization, we will just end up with a federated/fragmented system or a centralized one. We will keep repeating this loop over and over again until we fully appreciate that networks need built-in economics or someone else will build it and control them (see git/Github; RSS/Twitter; SMTP/Gmail; many others).
Oh wow so I'm not the only one who felt like this.<p>Having different unsynchronized servers has been a gigantic turn off for me.<p>That's like the one thing that shouldn't be the case with anything social online.
Why pretend request headers don't exist? Any app can send a request header to the same URL and have the response tailored, or am I missing something here?
You need to decouple the location of the url from the location of the resource. Like having a /resource/ branch with logic that decide which server have the resource and redirects or proxy or whatever to that content. And all locations have the same logic.<p>So, wherever you start on, you will access the content of the whole federation.
I don't think it's as huge of a problem as this article claims because:<p>a) you can request the same resource from multiple servers<p>b) it is not just the address bar which can control the server it's requested from -- servers can link to each other.<p>Of course, if one server is unavailable, the browser may not know to try another... but that's a small improvement which can be added.
So matrix:// just is a standard URI scheme, seems to solve at least this particular problem for the matrix.org ecosystem.<p>A different problem: While the federated protocols seem to work quite well, there's not enough work on the business development side of it. Or do you know any profitable Open-Access fediverse server?
Good point, but I think the feature that I can paste any fediverse URL into the search field on my own mastodon instance and view it there, solves around 40% of the problem.<p>There are also already browser extensions which automatically redirect you to your own instance I think, but those need access to all browsing :-/
If I run a local proxy, it can do all kinds of tricks. Think about VPNs and DNS resolution.<p>If I use an aggregator, it can do all kinds of tricks. Think about Usenet, email, RSS feeds.<p>If you build on top of IPFS or something, there's lots of options.<p>BitTorrent comes to mind.<p>There's lots of options.
All these discussions sound like people who don't know how cars work, but they do know how to use a wrench, screwdriver, etc, and they try to design new cars.<p>A "federated web app" is literally just a web app that uses OAuth. You can do "more federation" with OpenID or OpenID Connect. It seems "the fediverse" is intended for more of the same, but with specific data types (e.g. "social media data"), which does not seem scalable.
confused how the author is defining 'application'.<p>Is it a server-side or a client-side entity? Seems to use it interchangeably at different points in the text, perhaps purposefully, perhaps not. Or if there is another property that that defines it as an "Application", what is that? (and how is that different from a 'Resource')
Ghosh, a second “terrible take about the web” from Hugo Landau in a week (after the “I intentionally mix-up threat models and also I don't understand service workers”[1] we got on monday)…<p>[1]: <a href="https://www.devever.net/~hl/webcrypto" rel="nofollow noreferrer">https://www.devever.net/~hl/webcrypto</a>