this post was submitted on 27 Jul 2023
66 points (98.5% liked)

Fediverse

26800 readers
186 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to [email protected]!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 1 year ago
MODERATORS
 

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 [email protected] part with an ID? something like 6769052[email protected] 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

top 27 comments
sorted by: hot top controversial new old
[–] fubo 16 points 11 months ago* (last edited 11 months ago) (3 children)
[–] [email protected] 15 points 11 months ago

Found the feature request issue, it's at https://github.com/LemmyNet/lemmy/issues/2987

[–] [email protected] 2 points 11 months ago (1 children)

ok sounds like it's not a feature - the link format i suggested includes both the instance ID and the instance url, so it would be possible for your home server to use that to preprocess to a useable link. I wonder if there's a suggestions box 🙂

[–] marsara9 8 points 11 months ago (1 children)

I just got a PR merged today that might help with this. I'll start experimenting with it more over the next week or so.

Basic theory is that I can detect at least lemmy posts in the comment bodies and then rewrite those to your local instance. Primarily question is going to be performance, as remote network calls will be necessary.

[–] [email protected] 1 points 11 months ago (1 children)

oh that's awesome! yeah i can see it being an issue especially if that post isn't already federated. would be a great quality of life improvement though.

[–] marsara9 2 points 11 months ago* (last edited 11 months ago) (1 children)

Ya if it's not federated already, I'm thinking the link will just remain as-is? Then comes the question of what happens after federation is complete? Ideally I'm thinking to do these rewrites as the comment containing the link gets federated so it only happens once, but that prevents updates... If I do it during someone looking at the post, then that becomes a lot of network traffic...

Still a lot to plan out initially and then propose to the devs for feedback... So it'll be awhile still.

[–] [email protected] 1 points 11 months ago (1 children)

Ya if it’s not federated already, I’m thinking the link will just remain as-is?

yeah that seems entirely reasonable. it'll still be a big improvement in most cases. also even if it only happens as it federates initially it'll probably still catch many cases. is it possible to do a follow-up check only for links that weren't updated the first time? if you could store a cool-off and maximum number of tries that would probably keep it light and as functional as possible.

when serving posts with un-processed links that haven't been updated, and it hasn't been checked in the last 3 hours, re-check for a federated article and update. do this for up to 24 hours after the comment is posted, after that just give up? that gives it a few opportunities but doesn't continue to waste resources if it's unlikely the link will be resolved.

I'm not sure if it's easy to add columns to track those attempts though.

[–] [email protected] 2 points 11 months ago* (last edited 11 months ago) (2 children)

Yeah, I was disappointed that federation didn’t automatically log you in everywhere like Google across its services, or that you cannot just “log in with [your home instance]” like OAuth.
(See my other comment for pondering how this could work)

I even tried using my feddit.de credentials (with @feddit.de appended, of course) on another instance, assuming the website code would notice the @ and pass them on to feddit.de instead. @[email protected]

[–] [email protected] 3 points 11 months ago (1 children)

I got very confused and tried clicking all kinds of stuff, ending up with a dozen accounts across the Fediverse. I am not the only one who did, apparently.

[–] [email protected] 3 points 11 months ago (1 children)

You two can stop now. It's not funny.

[–] [email protected] 2 points 11 months ago

I think full federated auth across servers is a much more difficult problem - it'd be nice but outside the scope of this request!

[–] [email protected] 1 points 11 months ago (2 children)

What’s this post’s link for beehaw.org? I cannot see it at https://beehaw.org/c/[email protected] although some other posts are visible. I thought that I would see an “Error: defererated” message if that was the case.

[–] fubo 2 points 11 months ago

"Defederation" means that new posts aren't accepted from instance A to instance B; it doesn't (currently) generate an error if you try to access a community c@A on instance B.

[–] [email protected] 0 points 11 months ago (1 children)

Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: [email protected]

[–] [email protected] 1 points 11 months ago

No. That’s the point.

[–] [email protected] 10 points 11 months ago (2 children)

I have just been using this script. Simple and works great. Also, it let's you setup multiple home instances so if you have a back up account elsewhere to deal with downtime or an account for other things 👀 it's fantastic.

[–] [email protected] 2 points 11 months ago

I use this one as well. Works great.

[–] [email protected] 1 points 11 months ago

oh nice. thanks!

[–] Xylinna 7 points 11 months ago* (last edited 11 months ago)

There are a few browser extensions that you might like and are least worth checking out. Doesn't quite do what you are looking for but might help some.

https://github.com/FackJox/lemmy-link

https://github.com/cynber/lemmy-instance-assistant

[–] [email protected] 2 points 11 months ago* (last edited 11 months ago) (1 children)

I would prefer an OAuth-like solution where you can “Log in with” your home instance on other instances’ URLs.

Is there a way for your home instance to set a cross-site cookie, accessible by all federated servers, that would store its URL so that they automatically contact it for the login process? Setting up such a cookie should be optional but enabled by default on account creation, which would make federation very seamless. Ideally, it would happen without fetching JS from all federated servers, which would significantly load the tiny personal ones, although I doubt the technology is there.
Also, I assume that browsers block such cookies because they’ve been used to track people across websites.

And yeah, you could do that with browser extensions but you cannot get everyone to install one.

[–] [email protected] 2 points 11 months ago (1 children)

Is it so desirable to sent even more info, this time potentially non-public, if you decide to interact with the other instance?

This includes partial information about your online identity, namely identifying you uniquely. Not all instances should be considered trustworthy, so your log-in token may get re-used by a malicious instance to post things in your name here and there. Kind of a silly situation, favorable to spammers for example.

[–] [email protected] 2 points 11 months ago* (last edited 11 months ago) (1 children)

I don’t think the other site needs your login token. Assuming your home instance is lemmy.menf.in, I guess it would just

  1. See the fediverse-wide cookie (this technology may not exist yet) that your instance is lemmy.menf.in
  2. Fetch code from lemmy.menf.in that would verify your session with its own session token (if you don’t have automatic fediverse-wide login enabled, it will take you to a confirmation page first).
  3. The website will retain its URL but become nothing but a frame to embed the same content now fetched via lemmy.menf.in. You can safely interact using your account now.

Because the address bar URL remains the same, even non-technical users now understand that they’re viewing another instance while logged in via their own. Because this happens automatically for all instances whitelisted by lemmy.menf.in if you have automatic fediverse-wide login enabled, federation is now completely seemless and nobody complains. I understand that setting this up securely and compatibly might be difficult but could greatly simplify the UX because posts, comments, communities and user pages would have just one visible URL and no ambiguous IDs.

[–] [email protected] 1 points 11 months ago (1 children)

Wouldn't that overload popular instances even more? Right now, popular instances only need to accommodate their users, but with a "fediverse-wide" auth, soon they'll also have to serve content to people who followed that popular link to their content?

[–] [email protected] 3 points 11 months ago* (last edited 11 months ago) (1 children)

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

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

[–] [email protected] 2 points 11 months 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.

[–] [email protected] 1 points 11 months ago

I think you can paste the permalink into the searchbar and that would show you the original post that you can interact with

load more comments
view more: next ›