[HN Gopher] The problem with federated web apps
___________________________________________________________________
The problem with federated web apps
Author : hlandau
Score : 63 points
Date : 2023-07-01 12:06 UTC (10 hours ago)
(HTM) web link (www.devever.net)
(TXT) w3m dump (www.devever.net)
| revskill wrote:
| As i see, the fediverse was born to fight with monopoly systems ?
| ilaksh wrote:
| 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.
|
| 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.
|
| Tying web pages to specific servers is also maybe something that
| deep down people won't or can't accept or understand about
| changing.
|
| 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.
| gochi wrote:
| This doesn't really solve the problem, as it's incredibly easy
| to get IPFS support in your browser right now with a simple
| extension. No tinkering necessary. Yet IPFS is still rarely
| used, even within highly tech-literate communities.
| Pannoniae wrote:
| 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.
|
| The real solution would be a regular, centralised service run by
| a non-profit.
| David_SQOX wrote:
| Any amount of the use of words like "instance" or "federated"
| just confuse people. "Cognitive overhead" is the perfect phrase
| for this issue.
|
| In the RedditAlternatives sub you can find the most hilarious
| responses to "I don't understand lemmy, it's way too
| complicated!". Quickly someone will respond with "It's not
| complicated at all..." then proceeds to type out a paragraph of
| instructions and FAQs without a hint of irony.
|
| Like you said, users just want to hit the ground running. They
| don't care if your using php/asp/vbb/[insert a multitude of
| framework names here]..decentralized, partially
| centralized...they just don't want to know.
|
| For the record I do like Lemmy, but I'm a sucker for novel
| implementations.
| kelvinjps wrote:
| I would like to see a p2p architecture.Something that relies more
| on the clients,like how bittorent and rss work
| rurtrack wrote:
| 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?
| ape4 wrote:
| mail is federated, but web mail apps seem ok
| syllablehq wrote:
| I've had the opinion for years that any federated social media
| platform should fallback to email as a default. This helps
| solve the problem of bootstrapping an audience. You should be
| able to "tweet" at your friends by using their emails. It
| should show up on the public record as an unclaimed account.
|
| That account could authenticate at any time through their email
| to claim it. You could send a "tweet" by just sending an email
| to post@this-new-platform.com. [follow-up verification link can
| be sent to approve with one click to prove email.]
|
| I don't understand how this idea isn't more obvious to all
| these new platforms. We need to lower barriers to entry to
| decentralization.
| Brighthurst wrote:
| That's a good point and it illustrates what the solution is
| too. Email, is a series of protocols: POP3, SMTP and IMAP; thus
| they don't suffer issues with HTTP (a different protocol) that
| this article describes. The Web mail apps are just a client to
| serve your email protocol data to you. While the web apps do
| suffer from the HTTP issues, you at least have the freedom to
| switch your clients, and even the servers of your email data.
| notatoad wrote:
| webmail doesn't tend to have the problem of sharing pieces of
| content via hyperlink, which is the problem the author is
| talking about.
|
| fediverse apps do fine as clients to access pieces of content
| through their own dedicated communication channels, in the same
| way webmail clients do.
| gsatic wrote:
| Mail breaks down as soon as everyone starts broadcasting to
| everyone else.
|
| Also the reason why ppl behind mail and chat never saw social
| media coming. Social media can't work on top of those protocols
| so they thought it would fail.
|
| Nor did anyone imagine that everyone has such a desperate
| craving for Attention or this Need to broadcast their thoughts
| to the entire planet every day. Its still not clear why this
| even has any value. Its sort of like trying to build a brain
| where every neuron has broadcast capability to every other
| neurons. Our brains would just fry if such capability existed.
| There would be so much noise nothing would make sense.
|
| But ppl have decided this is what they need to build to escape
| Google and Facebook or whoever. And the whole story doesn't
| really make too much sense.
| platz wrote:
| confused how the author is defining 'application'.
|
| 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')
| tedunangst wrote:
| Mailing list posts show up on HN all the time, but I've never
| seen anyone complain that they can't reply right there in the
| browser.
| forgotmypw17 wrote:
| I don't think it's as huge of a problem as this article claims
| because:
|
| a) you can request the same resource from multiple servers
|
| b) it is not just the address bar which can control the server
| it's requested from -- servers can link to each other.
|
| 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.
| lolinder wrote:
| I don't think that the author explained it very well, but the
| difficulty with (a) is that currently, when you follow a
| fediverse link, it will open in whatever server the original
| poster uses, rather than your own server. Odds are you aren't
| logged into the same server that they were, so that leaves you
| unable to interact until you jump over to your own server and
| access the same document.
|
| This can be remediated somewhat within fediverse apps, because
| they can detect cross-server links and convert them into
| internal links if possible. But that doesn't help following a
| link from HN.
|
| There might be a browser extension already to solve this
| problem--it would need to know which instances your server
| federates with and how to translate links to those instances
| into links to your server.
| INTPenis wrote:
| I might be misunderstanding OP here but that's not how I see
| it. In fact, the Mastodon web UI frequently shows profiles
| and posts from other servers on your own "home" server, in
| your own format. All example.org (your home) does is request
| JSON from eample.com (the remote), and displays it in
| whatever format fits your home server.
|
| And it seems to me that it uses the first option that the
| author suggests, being example.org/user@example.com/thread
| lolinder wrote:
| That's when you _start_ on example.org. But if I copy and
| paste a URL to you and you end up on the post on
| example.com, the best that Mastodon can do is suggest that
| you search for the link on your home instance.
| rektide wrote:
| Axiom 2a of the web emphasizes this,
|
| > _a URI will repeatably refer to "the same" thing_
|
| And further,
|
| > _the significance of identity for a given URI is determined
| by the person who owns the URI, who first determined what it
| points to._
|
| Which explicitly goes on to say ownership is not well defined
| because different schemes can have different behaviors.
|
| https://www.w3.org/DesignIssues/Axioms.html#same
|
| The trick is to actually have clients know & understand where
| instead to link people. If a server shuts down how does that
| alt-location get persisted & spread?
|
| Effort has faced headwind, but I also really dig Signed
| Exchanges, which let's servers sign the content it sends & then
| bundle it together (WebBundles) so other servers can serve it
| in a trusted way. But the _browser_ will only trust the content
| for 7 days, because as per this article, the dns owner might
| change & thats the security compromise. But an app could still
| parse & use that content, which makes extra sense now that we
| have Certificate Transparency expectations.
| basch wrote:
| I agree where the author is going.
|
| A problem with the federation is the combination of the
| identification, client, and backend into an instance, yet
| depending on the web/nets dns. I'd like to see more of a
| separation between the account, client, and data akin to google
| reader / third party reader client / rss. Before reader shut
| down, you could log into any reader client with your google
| account and all your feeds followed.
|
| A good fediverse client would have separate settings pages for
| your accounts, and what you follow. I should be able to share a
| link to data that anyone can open in the client of their
| choice.
|
| Another way to solve the authors problem is to make a new
| protocol.
| Avamander wrote:
| > a) you can request the same resource from multiple servers
|
| Can I? With PeerTube for example it's a massive hit-and-miss.
| Many mirros don't have the torrents or vice versa. There's no
| reproducible way to mirror/federate YouTube content and so on.
| lyu07282 wrote:
| 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.
| ibz wrote:
| Nostr solves this. You don't need to "create an account", you
| just generate a key pair. That is your account. On what relays
| you store your data is orthogonal to this. As long as an event
| is signed by your private key, it is your event.
| conor- wrote:
| I think DIDs[0] are an interesting idea for dealing with the
| problem of centralized registration in federated systems.
|
| It would be great to be able to create one identity that if I
| want to leave an instance and bring all my data with me to a
| new instance I can do so without friction. That's currently a
| big issue I have with Matrix for example -- there's no way
| for me to go from @user:matrix.org to @user:myowndomain.com
| and have that be the same identity with the same friends
| list, etc.
|
| [0] https://en.wikipedia.org/wiki/Decentralized_identifier
| Arathorn wrote:
| We're currently working on account portability
| (https://github.com/matrix-org/matrix-spec-
| proposals/pull/401...) and experimenting with glueing
| bluesky style DIDs onto it (so as to provide DMs for
| bluesky via Matrix, should they want them)
| conor- wrote:
| Ah, as usual if there's a complaint there's an open spec
| proposal for it. Thanks for sharing!
| toyg wrote:
| The minute you introduce the concept of "key pair", you've
| lost 99% of people.
| lyu07282 wrote:
| True, but you might be able to store it/hide it away in
| some DHT behind a username and passphrase, even that might
| not be necessary. You can solve a lot of complexity in the
| protocol by good frontend people who understand UX.
|
| Even Whatsapp is using PKI, its just all hidden away from
| the user.
| nickorlow wrote:
| Yeah, Apple's passkeys is trying to do this too. Their UX
| is good but it's still pretty immature
| DANmode wrote:
| I think this is the decade this problem goes away.
|
| Of course, the phrase that gains traction won't be
| "keypair".
| mac-chaffee wrote:
| That looks closer to the right solution, but...
|
| > Remember, your private key is your identity in Nostr, so if
| it is compromised you'll lose your followers and will have to
| start from scratch rebuilding your identity.
|
| This is the same gripe I have with home servers on the
| fediverse: home servers come and go, and private keys
| sometimes need rotating. Making you lose all your friends and
| content when that happens is not an acceptable tradeoff.
|
| I think the solution is entirely separating "identity" from
| every single other concern such as security (private keys),
| hosting (home servers), and public identity ("display name").
| INTPenis wrote:
| Yeah Nostr is cool but like others have pointed out, there's
| an even steeper learning curve. And besides that, Nostr
| claims to be censorship proof, which sounds cool on the
| surface but will inevitably lead to a cesspool of hate and
| personal attacks.
| mid-kid wrote:
| unlike censored platforms like twitter that become a
| cesspool of hate and personal attacks. as usual it depends
| on who you interact with.
| INTPenis wrote:
| Twitter has the option to steer the moderation in any
| direction they want.
| Brighthurst wrote:
| Yeah, as far as I can tell, nostr does indeed solve the
| issues discussed ITT. I think it stems from the fact that
| nostr is a protocol, just like HTTP. So instead of federating
| or decentralizing on top of http, we needed a different
| protocol all-together
| sieabahlpark wrote:
| [dead]
| imtringued wrote:
| Either you control what is being relayed or you don't. The
| latter was not very successful (zeronet was a CSAM cesspit).
|
| If you choose control then you end up with the fediverse,
| because there is no such thing as the "one big fediverse" if
| every moderator makes different decisions.
| [deleted]
| mcdonje wrote:
| Tim Berners-Lee's Solid project is working on that. Put data in
| "pods" that are stored on pod servers, which are federated. You
| can self-host.
|
| It could be a federated layer of identity & personal content
| decoupled from social platforms.
|
| https://solidproject.org/
| jameshart wrote:
| > 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
|
| You keep using the word 'fediverse'. I do not think it means
| what you think it means.
|
| The whole _point_ of a 'fediverse' is that there isn't a
| central authority for accounts. That an account on any of the
| federated systems is an equal participant in the system. That
| spinning up your own federated host to issue accounts is
| allowed.
| INTPenis wrote:
| That'll never happen for two reasons, decentralization means a
| user-driven internet. It has to, even if corporations have the
| freedom to join, decentralization by default means any private
| person can host a part of it.
|
| And when users host things they give of their own resources to
| other users, which means there is trust involved. And whenever
| trust is involved we need a better insight into who signs up.
| For example; request access with a bio, or a donation.
|
| The other reason is that what you describe is centralized
| authentication, to a decentralized backend, so it defeats the
| purpose. Who owns the authentication?
|
| If we want freedom from a corporate internet, we'll just have
| to bite the bullet and accept a certain learning curve.
|
| Which is also why the centralized corporate services will never
| go away, and most likely remain a majority.
| nickorlow wrote:
| Yeah, I agree it all feels very disconnected. I think this
| problem extends to the communities on federated platforms too.
| Taking a look at the Reddit like federated alternative (lemmy),
| there's multiple instances of the same 'subreddit' on different
| servers. Makes it hard for everyone to gather.
|
| I think federated projects really look at federation as an add
| on to their platform, not a core feature. E-Mail did this well
| where everything was automatically federated by default (I.e
| you can send email from anywhere to anywhere for the most part)
| whereas some fediverse software, specifically lemmy, require
| that federation be enabled (and I believe you choose to
| federate with servers on a per-server basis).
|
| Where I work we're working on a solution to this where your
| identity remains sovereign between servers [1]. We currently
| have a Twitter-esque microblogging demo setup [2].
|
| [1] https://gitlab.futo.org/polycentric/polycentric
|
| [2] https://polycentric.io
| postpawl wrote:
| There's an open issue on Lemmy's GitHub about making it
| easier to combine multiple communities on separate instances:
| https://github.com/LemmyNet/lemmy/issues/818
|
| Seems like something they're thinking about solving.
| ktosobcy wrote:
| But email is the same as xmpp or DMs on "social media" - you
| can comunicate with various instances. the problem arise with
| groups (so mailing list, multi user chat or "communities") -
| in case of email you have mailing list which is not federated
| and is tied to particular server / address... same issue so
| it wasn't exactly solved. it's just it's used slightly
| differently.
| tuukkah wrote:
| All I get from polycentric.io is "Please add Polycentric to
| your home screen" (Android browsers call it installing) -
| even after I added it to my home screen (Firefox on Android).
| Works on Chrome though.
| nickorlow wrote:
| We'll look into it. Thanks for checking it out
| lolinder wrote:
| The big problem with federation-by-default in the current
| incarnation of federated software (at least Lemmy, I'm less
| familiar with Mastodon) is that you will likely end up
| publicly hosting any content from instances that you choose
| to federate with.
|
| With email, it doesn't really matter if someone is using your
| email platform to spread controversial political ideas or
| using it to share pirated media or whatever, because you're
| not hosting it for the general public to consume.
|
| With the fediverse it's different. If I own fedifoo.app and
| allow my app to federate with neonazis.app or tankies.app,
| then eventually neonazi or tankie content will be accessible
| at fedifoo.app/c/unpleasantcommunity. I don't want that, so I
| defederate, but now the fediverse is fractured and "it
| doesn't really matter which instance you choose" is no longer
| true.
|
| Disabling federation by default helps protect new hosters
| from the unintended consequences of federation, which is
| good, but it leaves us starting out on a fractured footing.
| AnthonyMouse wrote:
| The solution to this is to have a unified namespace which
| is distinct from hosting. So then /c/unpleasantcommunity is
| only hosted by instances that choose to mirror it, but if
| anybody goes to /c/unpleasantcommunity and their default
| instance doesn't mirror it, it redirects to an instance
| that does.
|
| Then you don't have to host anything you don't want to but
| you still have a unified network.
| cassianoleal wrote:
| Basically Usenet then?
| nickorlow wrote:
| Yeah, I also think having the option to censor
| communities in specific is a good way to do it. So you
| could just choose not to host /c/hatefulcommunity. I'd
| imagine blocklists and community reputation systems would
| be created much like what exists with e-mail.
| willi59549879 wrote:
| i quite like how censoring is done in the fediverse.
| there is no censoring but each user can chose to block
| content from showing up in the client. i don't like the
| idea of censoring. some authority decides what other
| people are allowed to see.
| nickorlow wrote:
| I like it in principal, but I think it's hard to keep up
| with spam in a manner like this.
| AnthonyMouse wrote:
| The generally right way to do this is to put actual
| censorship on the far side of impossible but give
| individuals good filtering tools. So then maybe your
| instance provides a default blocklist, but if something
| gets blocked, it isn't just silently invisible, it shows
| up as a collapsed comment that you can unfurl or a
| warning page that you can click through if you really
| want to. And if you don't agree with an entry your
| instance added by default, you can strike that one out
| and choose to always see it.
|
| The key is to never let anything like a central party
| impose censorship that can't be overruled by the user,
| but still allow them to filter out 99% of the crap by
| default.
| nickorlow wrote:
| Yeah, Polycentric lets server operators choose to censor
| individual posts or entire users. Your client can query
| anything that's censored from one server by querying it
| from another where the content was published. It's fairly
| easy to tell when a post is censored since each post has
| a logical clock per user that is incremented per post, so
| you can pick out any missing logical clock entries.
| jdthedisciple wrote:
| Oh wow so I'm not the only one who felt like this.
|
| Having different unsynchronized servers has been a gigantic turn
| off for me.
|
| That's like the one thing that shouldn't be the case with
| anything social online.
| postpawl wrote:
| The centralized platforms seem doomed to reach a point where
| they're squeezing as much cash out of users as they can while
| users provide their content for free. If we need to create
| multiple accounts to fight back against enshittification, I
| think that's a fairly minor downside for increased competition.
| m4lvin wrote:
| 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.
|
| There are also already browser extensions which automatically
| redirect you to your own instance I think, but those need access
| to all browsing :-/
| sacnoradhq wrote:
| Phony "federated apps" are mostly "fragile self-hosted with
| linkrot, convenience, and pseudo robustness".
|
| Robust federation works as a distributed overlay network and
| doesn't require any leader. The irreducible issues become:
|
| 0. "Which systems should store what data, i.e., blobs (files),
| entities, and entity sequences?"
|
| 1. "How many copies should there be of 0.)?"
|
| (1.5. "What will keep scrubbing 0.) for integrity and duplicating
| 1.) below a given threshold?")
|
| 2. "Where should functions against 0.-1. run?" #
|
| 3. "How many copies of 2.) should execute?" #
|
| 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 #.)
|
| 5. "How many copies of next nodes and node paths do you
| maintain?"
|
| 6. "Which nodes should this node remain connected to?"
|
| 7. "How many fixed default nodes can be run around the world to
| always seed a node's initial network topology?"
|
| 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.)
|
| # If the platform has a serverless function concept, where it's
| unknown where it will run until it does.
| acidburnNSA wrote:
| > 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
|
| 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:
|
| > 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.
| faraggi wrote:
| Funny because Andersen also made the choice to use text based
| pages instead of binary with the same profile in mind- making
| it easy for users to make stuff.
| INGSOCIALITE wrote:
| 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.
|
| What if the random one I pick gets defederated? Now I need to
| find a new instance and make a new account?
|
| 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.
|
| I honestly think it may be worse for free speech.
|
| 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.
| jayGlow wrote:
| the lemmy instance I've looked at is already a terrible echo
| chamber, as bad as some of the worst parts of reddit. I think
| defederation is going to lead into more insular communities
| unfortunately.
| gmuslera wrote:
| 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.
|
| So, wherever you start on, you will access the content of the
| whole federation.
| nickorlow wrote:
| I've thought about trying to do something like this as a side
| project. For lemmy in specific, I think having a "lemmy
| directory" that redirects urls to their correct server would be
| nice. (I.e lemmydir.com/c/homelab would 301 to
| lemmy.ml/c/homelab. People would register their redirects on a
| FCFS basis and some amount of activity on the community would
| be required to register the redirect)
| 9kaka001h wrote:
| [dead]
| pferde wrote:
| Matrix tries to solve this with matrix.to
| (https://github.com/matrix-org/matrix.to), which will eventually
| hopefully segue into a separate matrix:// protocol in URIs.
| mattdesl wrote:
| 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.
| ibz wrote:
| > you would need to decouple the resource being accessed from the
| application being used to access it
|
| Nostr does exactly this.
| Brighthurst wrote:
| Yeah, I think nostr is the obvious solution when you realize
| this article is all about the issues of
| federating/decentralizing on top of HTTP. The P in HTTP is
| protocol. So the solution is that we need a different protocol:
| nostr
___________________________________________________________________
(page generated 2023-07-01 23:00 UTC)