I notice often people might cross post something and say (for instance) cross posted from https://lemmy.ca/post/1916492 (random example which is the link that I just followed)

Is there any way to format a link like that so your home instance will just open it up so you're still logged in and can interact with it?

The link I followed goes to the Canadian lemmy server but it's actually looking at a post from beehaw.org, so it's extra useless 😒

Eg, if we could use the !technology@beehaw.org part with an ID? something like 6769052!technology@beehaw.org and our home instance could parse it to a link, with some tools to make it easy to add?

EDIT: This isn't a feature, but there is a github issue feature request at https://github.com/LemmyNet/lemmy/issues/2987 for exactly this

EDIT 2: appears to be a userscript solution, but i haven't tried it. lives here though: https://git.kaki87.net/KaKi87/userscripts/src/branch/master/fediverseRedirector/README.md

you are viewing a single comment's thread
view the rest of the comments

[–] ChaoticNeutralCzech@feddit.de 3 points 1 year ago* (last edited 1 year ago) (1 children)

I think the server load increase from cross-instance browsing will be low. The extra load only really comes when:

Users with the fediverse-wide cookie follow a link to another instance: A tiny HTML+JS site (the embed frame) will be loaded from the content-hosting instance, in addition to the same server having to serve the content to the home instance server. This piece of HTML+JS will remain loaded as long as the client’s browser tab is open and on the domain. Even the URL can change in sync with the embed frame going to various pages thanks to the JS. As such, the load increase is constant for each session and rather small.
The one I am really worried about: Setting the fediverse-wide cookie. AFAIK, cross-domain cookies currently only work through embeds so when a user clicks “automatically log me in on each whitelisted Fediverse site”, it will need to get a response from all federated servers (feddit.de has 4250)! Many of these are single users’ personal servers and will not handle even a small ping whenever a user registers at a federated instance. We might need new web technology for cross-domain cookies or a central server just for content-less requests that do nothing but allow other domains to share a cookie, which somewhat defeats the point of the Fediverse. Please suggest another solution if you are an expert in web technology. Yes, it could be and is being solved with browser add-ons but you cannot push every new user to install one because that would just increase the barrier to entry.

Anyway, I’m quite tech-savvy but one of the first things I saw on Lemmy was “if your account is hosted on another instance, you will not be able to log in” and thought “so federation does not exist?” I hope you understand how this is discouraging: at present, federation is anything but straightforward.

[–] samae@lemmy.menf.in 2 points 1 year ago

I hope you understand how this is discouraging: at present, federation is anything but straightforward.

There's also a question of perspective. If you approach federation with the mindset that it will be like the sort of SSO you get with using google products, microsoft ecosystem, or facebook to log in to many websites, then yes: it's doesn't look straightforward.

If you approach it with the perspective that the coupling between fediverse applications being more loosely coupled, and have the way email work in mind, then it is actually more natural. Each application can do their own thing, and provide all or partial compatibility with the fediverse. Think of a blog application, which rely on the fediverse only for the comment section of each blog posts, but also does other things specific to that application. Taking the example of email again, nobody thinks they should be able to log-in to microsoft outlook using their gmail account, or to gmail using their home-made account, in order to read and send emails.

There's a narrative aspect to it too.