Automatically stay on an instance, when given a link to another

[Kommynct]

Sometimes when I click on a link to another instance, it takes me to that instance, effectively signing me out, since lemmy is federated, this adds complexity to end users for minimal benefit

An option to automatically make links redirect to that community on your instance, instead of linking to a new instance, this should be toggleable and probably on by default, to decrease the confusion of new users.

[dessalines]

I agree, we could benefit from having the !... autocomplete link to both the federated, and local url of the community or user being linked.

[Deebster]

One problem is that this link can 404, if the local instance hasn't pulled down the community. I briefly looked at doing something automatic with the search page, but the current websockets-based querying means you can't just do /search?q=!foo@bar.

I suppose the real fix would be to make the local instance try to fetch the remote instead of 404ing (perhaps using a HTTP 202 instead).

[elishamint]

IMO, this should be higher priority (bug), as it currently defies federation and is very confusing.
Also, URIs should be more descriptive, including the community name.

[rubythulhu]

perhaps browser extensions could be made that transfer a user to their "home instance" when loading a link to a foreign instance? they could even check for the local instance hasn't pulled down the community first, and if not, display the original page but with a warning at the top explaining why it's not on your home instance?

[Kommynct]

Why should it be a browser extension? It should really be baked into the UI, I would go so far as to say this is a necessity for new users, because the current system is confusing

[rubythulhu]

Why should it be a browser extension? It should really be baked into the UI, I would go so far as to say this is a necessity for new users, because the current system is confusing

i wasn't suggesting this as a primary solution; i agree that this is an underlying problem with the platform itself. but browser extensions are a pretty good bandaid to the problem in the short term

[Kommynct]

I also want to brainstorm if there's a possible solution for external links, currently people are posting links all over reddit to the different instances, and people think you have to sign up for every single one to see content, is there any way to make sign-ins universal across lemmy? I doubt it, but it would be massively helpful for onboarding.

[elishamint]

The challenge, in a nutshell:
(1) With a logged-in user, the "local" (home) instance is supposed to serve the linked page. Meaning, the link should point back at the server (self, local) which served the page containing the link, in the first place.
(2) Each instance manages a database with the posts separately [edit: with the primary DB key functioning as the post ID, not sure if this is technically the case but no matter]. Thus, a post that has been pulled in from another instance will get a new ID assigned. The ActivityPub protocol requires it though, that the original ID be preserved, so we should be able to use that for DB query. I assume that there is no universally unique post ID (which is a design flaw IMO, [that causes the at hand in the first place - edit: incorrect, please excuse my tiredness])(*).
(3) As Links are a part within the text of a post, and contain no universal ID, links created can only point at the original location/ID (which is unique [edit: but not universally persistant]), which in case of a federated post becomes a remote link. (unless we go to the length of parsing posts and replacing post IDs, which could be inefficient)

We could therefore, as a work-around(*), make a link that omits the domain part, which will make browsers and apps send the request to (local).The (local) instance would search the DB by original ID, and can fetch the requested post if it hasn't yet been done so.

We would do good by making this human-readable and parse-able by 3rd-party clients.
My mock-up therefore suggests that the URI contains two pieces of info which are not strictly necessary for the web interface to work: the name of the community the post belongs to, and a network identifier (which an app could hopefully use to decide it wants to parse the URI instead of having it call up a web browser component.

[https//{local.domain}] /post/{originID}?net=lemmy&c={community}@{origin.domain}
[in brackets is the omitted part which will therefore be assumed by the browser]

(*) The way this needs to be done cleanly, is by introducing a hash of the (post&user&time) into the post metadata, as universal [edit: and persistant] Post ID. It is made once at first save, and never subsequently changed. This will [edit: unbind the post ID from its domain and primary DB key, and] subsequently allow for migration of communities between domains, without breaking existing links. The same applies to users.

Edited for clarification and refinement.

[krestenlaust]

I suppose the real fix would be to make the local instance try to fetch the remote instead of 404ing (perhaps using a HTTP 202 instead).

This should probably be a separate issue, but I would classify it as a bug/oversight.

[krestenlaust]

Same issue as #369

[nnhien]

Gonna copy and paste this proposal I made on my PR here; Any thoughts are welcome.

---

I imagine that all we're doing on the frontend is a search and replace for text of a particular format to render a link.

The Tribute autocomplete is just a "nice-to-have", but is ultimately particular to Lemmy UI's implementation. If a local instance isn't federated with a particular remote, I think the user should still be able to manually put just !asklemmy@lemmy.ml in their comment. Text of that form would semantically mean that people should go to asklemmy on the lemmy.ml instance in whatever way their UI supports.

Particular UI implementations which support this format could render the text to be a link which refers to a location on their local instance which makes content from the appropriate remote community/instance pair viewable, but implementing this feature isn't required for other UI implementations.

---

For some context, the motivation behind my proposal is to keep content implementation agnostic. A concern of mine is that if we just stick a /c/{community}@{instance} hyperlink in, we break link interoperability with other federated services like KBin, since they use a /m/ prefix to denote communities in remote services. If we just keep it simple and leave the link as plaintext which has semantic value, we can have each UI implementation render the link in a way that navigates the user within the local instance. For example, in Lemmy UI this rendering could occur when each Comment Node is rendered by React.

By semantic value, I mean we establish an implicitly understood standard where a string with format !{community}@{instance}, which to the user means "Go to {community} on instance {instance}". That way if their UI implementation doesn't support rendering Lemmy Community Links, the user still knows where OP is intending for them to go to. This is similar to how reddit does /r/{subreddit} and automatically links it. Even if the reddit client didn't support automatically linking /r/{subreddit} formatted words, redditors still know to go to that particular subreddit. The Lemmy version simply encodes a little more information, namely the instance domain, since that's a requirement for a federated service.

As a related point, I also think we should only have a single link rather than two links. I think we should make navigating Lemmy as transparent as possible. A user who isn't technically inclined shouldn't need to know about the nuances about how instances work (i.e. the difference between a local and remote instance) in order to navigate content. The process should be as transparent as possible; i.e. they should be able to click on links and get their funny memes without having to think about the federation.

[nuiva]

On a related note, RSS feeds are always from the original instance because of #53. That is, if I go to https://lemmy.ml/c/lemmyworld@lemmy.world, the RSS link is https://lemmy.world/feeds/c/lemmyworld.xml?sort=Active, and all the URLs served by the RSS will then also point to lemmy.world directly.

As far as I see, the only reasonable fix is to have every instance host their own RSS feeds for every federated community.

[krestenlaust]

Links to posts and comments are also worth mentioning. I believe they also should be opened within the local instance, but then we'd need a more general solution rather than just treating !{community}@{instance} specially.

[elishamint]

nuiva:

As far as I see, the only reasonable fix is to have every instance host their own RSS feeds for every federated community.

This, or enable federated log-in, which would have an additional huge benefit.

[krestenlaust]

Federated log-in isn't possible. It's preferable to use reactions to express agreement, as to not clutter a thread

[nnhien]

As far as I see, the only reasonable fix is to have every instance host their own RSS feeds for every federated community.

Forgive me for being dense, but what do RSS feeds have to do with links to other instances in comments? Is it that we should aim to have consistent behavior between features?

[nuiva]

@nnhien: OP discussed links in general, not just links in comments. But yes, it's good to have consistent behaviour for all links.

[alexispurslane]

This would be so helpful to have, seriously. I cannot overstate how much nicer it'd be!

[alexispurslane]

One problem is that this link can 404, if the local instance hasn't pulled down the community. I briefly looked at doing something automatic with the search page, but the current websockets-based querying means you can't just do /search?q=!foo@bar.

I suppose the real fix would be to make the local instance try to fetch the remote instead of 404ing (perhaps using a HTTP 202 instead).

Maybe this could be solved by trying to go to the community via the local instance first, and only if that 404s redirecting to the community on its hosting instance as a fallback?

[Falmarri]

Is there an option to do both. What i mean is, reddit will automatically fill in the url if you just do r/subreddit. So if a user writes in a post (or a link somewhere, like above the subscribe button) is just linked as c/technology@beehaw.org, it will auto fill for the current instance. But if someone in a posts the literal "https://beehaw.org/c/technology", it shouldn't be rewritten.

Maybe that's what you all area talking to. But I agree with the confusion, being dumped into a new instance from clicking on links in NON-USER created content (that is, on the official UI) is confusing.

[kargaroc]

This is super important yeah.

[krestenlaust]

Is there an option to do both. What i mean is, reddit will automatically fill in the url if you just do r/subreddit. So if a user writes in a post (or a link somewhere, like above the subscribe button) is just linked as c/technology@beehaw.org, it will auto fill for the current instance. But if someone in a posts the literal "https://beehaw.org/c/technology", it shouldn't be rewritten.

I partly agree, but that's a minor detail.

This is super important yeah.

Please refrain from commenting just to agree, we have reactions for that. No worries though, this comment kinda does it as well.

[trashhalo]

Right now the format of is effective but browsers and OSes don't recognize them, or worse, recognize them as emails.

This is only true because the text being rendered as raw text and not a link by the markdown parser. Markdown-it uses linkify and has the ability to register new link types that start with a special character. This is used to turn things like @trashhalo into clickable links on github/twitter.

I outlined the technical steps that would be required to add a link handler for lemmy on this ticket. #1297 (comment)

[Zetaphor]

Hello all, please see #1462. I've begun working on this and am seeking feedback and contributions.

[dkniffin]

After doing a bunch more digging, it seems there is no client-side way to share data between domains.

If we also eliminate the option of requiring users to install additional software (eg a browser extension, or something to recognize new protocols), and any sort of centralized solution, I don't think there's any way to automatically redirect the user to their home instance.

So I think that means the least-friction way to handle new users would be to have something in the UI to inform them what's happening, and allow them to navigate to the home domain easily. Maybe when the user clicks "Login", they have the option to select their home instance. If they do that, they're simply redirected to the same page in that instance. We could also provide information there about a browser extension that would make that process more seamless, if users chose to use that.

Something like this:

[trashhalo]

Mastodon has a similar issue. Here is what that dialog looks like on mastodon after clicking follow.  Edit. Image not embedding click link

[robbell]

Mastodon has a similar issue. Here is what that dialog looks like on mastodon after clicking follow. Edit. Image not embedding click link

Mastodon Share is an interesting workaround for Mastodon although I don't think it suits the decentralised model:

https://mastodonshare.com/

[Dakkaron]

I think there is a pretty simple solution that would also be consistent with the way communities and users are handled.

Say I am on instance myinstance.org, and there is a user anotheruser on anotherinstance.org. If I want to access their profile, I will go to https://myinstance.org/u/anotheruser@anotherinstance.org.

The same pattern could easily be extended to posts/comments.

Say there is a post on anotherinstance.org that I want to view. On the remote instance, it has the ID 1234 and on my local instance it is ID 4321. So right now I can access it as https://myinstance.org/post/4321.

So to do the same as with users/communities, we would add a second url that leads to the same post locally: https://myinstance.org/post/1234@anotherinstance.org.

Both of these links should act exactly the same. This should only work for linking to posts on the instance where the post originated from. It would be quite easy to do, because right now the database already contains a link to the origin post on the origin community. We would just have to expose that URL on the API.

Now any user can post a relative link to that post as /post/1234@anotherinstance.org. Since relative links auto-fill the local domain, this link will always link to the instance that the user is currently on.

The last thing left over is the question how to handle 404 scenarios, and that, too, would be rather simple.

Add a descriptive 404 page like that:

This post/comment is not currently available on this instance.

Press this button to try to make it available.

If this is not possible, head to this link to view it on the origin instance (Link to https://anotherinstance.com/post/4321).

Warning, you will leave the current instance (myinstance.org) when you follow this link

[ChaoticNeutralCzech]

I have another idea to make federation more seamless: OAuth-like automatic "login" on all whitelisted instances (actually just embedding the home-instance-fetched version in pages under the content-hosting instance's domain). The feature would be applied at signup unless the user opts out. However, I don't think present web technology (where cross-domain cookies are blocked for good reasons) allows this without excessive load of all servers upon initialization, a centralized server (that defeats the purpose of the Fediverse) or a browser extension (which increases the barrier to join). Just something to think about. Discussion We could even eliminate ambiguous links to content with this!

[alyxto]

I have the feeling this issue is getting off track again.
Please don't get me wrong, some other ideas are good but just not related to the topic this issue was about.

I consider this issue solved with #1462

[Atemu]

I agree that what @ChaoticNeutralCzech said is a topic for another issue but I don't think this issue is resolved as thread and comment links will still take you to another instance.

Solving that might require better thread/comment identifiers that are stable across instances.

[alyxto]

Oh, I'm sorry you are right.
I kinda assumed that #1462 also converts links to comments.

I guess this would require more actions than just the markdown module..
Lemmy then probably needs to actually resolve links in the posts/comments and if it is a lemmy or kbin instance convert the link to the same post/comment on the local instance.

It would also need to trigger a fetch for the comment in case it is not yet known by your local instance.

[Dakkaron]

The easiest solution for that would be for the post/comment endpoint to work like the community endpoint.

So for example:

There is a post on instance A.org with the ID 1.
The same post is replicated on instance B.org with the ID 7.

Currently you could access the post under

https://a.org/post/1

or

https://b.org/post/7

My proposal would be for all replicated posts to be reachable by the original id, followed by an @originalinstance as well, like so:

https://b.org/post/1@a.org

The data for that is already in the database field ap_id, so the migration would be rather easy. Also, this would be consistent with the way the other entities (communities and users) are handled.

The UI would then only need to do some markdown trickery like with the communitys.

So a link to a post would just automatically link to /post/1@a.org, which is a relative link, so anyone on any instance could follow it and end up in the right place.

[MetalZealot]

Or, at least a pop-up that asks you if you would like to view this in it's original instance, or from within your own. Since both display different results in comments /votes

[krestenlaust]

Since both display different results in comments /votes

In theory, there shouldn't be a discrepancy in votes/comments, so developing with it in mind seems unwise. Sounds like a job for an extension

[Pxtl]

Ideally I'd like the link to have some kind of [...] icon next to it. So like "click here to see SomeOtherCommunity [...]" where if I click SomeOtherCommunity I get the local link, but if I click [...] I get a dropdown with

• view link on this instance
• view link on its original instance
• view information about the relationship between my instance and the remote instance (are they federating normally?)
• help (what the hell are you talking about with instances?)

[Schmork]

Or, at least a pop-up that asks you if you would like to view this in it's original instance, or from within your own. Since both display different results in comments /votes

In theory, there shouldn't be a discrepancy in votes/comments, so developing with it in mind seems unwise. Sounds like a job for an extension

Instances A, B, D. A and B are federated with both others, but D defederated from A. Users from all instances can participate in communities on B. But users from D won't see posts, votes and comments made by users from A on B.

So it's not only a sync issue, if you meant that. Communities, posts and comments can look different when viewed from different instances, depending on their federation status. This is a consequence of partially federated and defederated networks.

For the same reason, I find it important to be able to choose from which instance's perspective I'd like to see something.

[TheVillageGuy]

This should really be solved. When I link to a community on my instance from lemmy.world, I can tell by the amount of hits (>100) on the login page how many people don't understand that they have been transferred to another instance, and that instead they can subscribe via their own instance. I don't want the link to make them visit my instance, I want the link to bring them to the community on their own.

[Die4Ever]

This should really be solved. When I link to a community on my instance from lemmy.world, I can tell by the amount of hits (>100) on the login page how many people don't understand that they have been transferred to another instance, and that instead they can subscribe via their own instance. I don't want the link to make them visit my instance, I want the link to bring them to the community on their own.

you're not using the !communityname@instancename.com format for community links?

[TheVillageGuy]

You are right, that does now work

…

On Fri, 29 Mar 2024, 18:11 Die4Ever, ***@***.***> wrote: This should really be solved. When I link to a community on my instance from lemmy.world, I can tell by the amount of hits (>100) on the login page how many people don't understand that they have been transferred to another instance, and that instead they can subscribe via their own instance. I don't want the link to make them visit my instance, I want the link to bring them to the community on their own. you're not using the ***@***.*** format for community links? — Reply to this email directly, view it on GitHub <#1048 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALKLYOEG5CYFS6YUKINZKD3Y2WOEVAVCNFSM6AAAAAAYXZS3D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGUYDOMJZG4> . You are receiving this because you commented.Message ID: ***@***.***>

[ericjmorey]

What progress has been made on this issue? What is the next step?

[RandomDennisLee]

What is the next step?

To get a similar solution in place for comments and links

[Die4Ever]

Another way to do this: #2318

[Die4Ever]

Also I would like to point out that this issue is still part of the 0.18.2 milestone, which is hidden because that milestone is closed even though this issue is not. And there are other open issues which are hidden in the same way.

https://github.com/LemmyNet/lemmy-ui/milestones?state=closed