8 ms·

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 addre

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.

basch 3y ago
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.
lolinder 3y ago
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 3y ago
  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 3y ago
    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.
  - shagie 3y ago
    The HN article Twitter Is DDOSing Itself (sfba.social) https://news.ycombinator.com/item?id=36553236 https://news.ycombinator.com/item?id=36553236 links to https://sfba.social/@sysop408/110639435788921057 https://sfba.social/@sysop408/110639435788921057 The instance of mastodon that I have an account on is https://techhub.social https://techhub.social I can't interact with the sfba.social toot directly. Clicking 'boost' (retweet) gives me instructions: > With an account on Mastodon, you can boost this post to share it with your own followers. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. > On a different server > Copy and paste this URL into the search field of your favourite Mastodon app or the web interface of your Mastodon server. --- Similarly with 'reply'. So, I can only interact with that toot on my home instance which is a bit of friction. Not necessarily a bad thing, but there's friction there. Mastadon isn't too bad however. Interacting with it on my home instance only brings that toot over. One and done. Subscribing to a community or trying to interact with a post in Lemmy, however, puts a larger and ongoing operational cost on the server as new comments appear and votes are cast.
- ummonk 3y ago
  Thank you for explaining. I couldn't make heads or tail of what the article was saying, and most of the comments in this thread are discussing different problems with federated services, rather than specifically this problem with federated web apps.
rektide 3y ago
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 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.
Avamander 3y ago
> 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.

basch 3y ago

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.

lolinder 3y ago

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 3y ago
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 3y ago
  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.
- shagie 3y ago
  The HN article Twitter Is DDOSing Itself (sfba.social) https://news.ycombinator.com/item?id=36553236 https://news.ycombinator.com/item?id=36553236 links to https://sfba.social/@sysop408/110639435788921057 https://sfba.social/@sysop408/110639435788921057 The instance of mastodon that I have an account on is https://techhub.social https://techhub.social I can't interact with the sfba.social toot directly. Clicking 'boost' (retweet) gives me instructions: > With an account on Mastodon, you can boost this post to share it with your own followers. Since Mastodon is decentralized, you can use your existing account hosted by another Mastodon server or compatible platform if you don't have an account on this one. > On a different server > Copy and paste this URL into the search field of your favourite Mastodon app or the web interface of your Mastodon server. --- Similarly with 'reply'. So, I can only interact with that toot on my home instance which is a bit of friction. Not necessarily a bad thing, but there's friction there. Mastadon isn't too bad however. Interacting with it on my home instance only brings that toot over. One and done. Subscribing to a community or trying to interact with a post in Lemmy, however, puts a larger and ongoing operational cost on the server as new comments appear and votes are cast.
ummonk 3y ago
Thank you for explaining. I couldn't make heads or tail of what the article was saying, and most of the comments in this thread are discussing different problems with federated services, rather than specifically this problem with federated web apps.

rektide 3y ago

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 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.

Avamander 3y ago

> 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.