lemmy-ui icon indicating copy to clipboard operation
lemmy-ui copied to clipboard

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

Open Kommynct opened this issue 1 year ago • 74 comments

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.

Kommynct avatar Jun 02 '23 04:06 Kommynct

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

dessalines avatar Jun 02 '23 14:06 dessalines

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

Deebster avatar Jun 09 '23 01:06 Deebster

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.

elishamint avatar Jun 09 '23 11:06 elishamint

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?

rubythulhu avatar Jun 10 '23 23:06 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

Kommynct avatar Jun 10 '23 23:06 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

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

rubythulhu avatar Jun 11 '23 00:06 rubythulhu

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.

Kommynct avatar Jun 11 '23 01:06 Kommynct

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.

elishamint avatar Jun 11 '23 01:06 elishamint

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 avatar Jun 12 '23 08:06 krestenlaust

Same issue as #369

krestenlaust avatar Jun 12 '23 09:06 krestenlaust

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 [email protected] 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.

nnhien avatar Jun 12 '23 22:06 nnhien

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/[email protected], 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.

nuiva avatar Jun 13 '23 04:06 nuiva

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.

krestenlaust avatar Jun 13 '23 06:06 krestenlaust

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.

elishamint avatar Jun 13 '23 09:06 elishamint

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

krestenlaust avatar Jun 13 '23 13:06 krestenlaust

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?

nnhien avatar Jun 13 '23 15:06 nnhien

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

nuiva avatar Jun 13 '23 19:06 nuiva

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

alexispurslane avatar Jun 14 '23 12:06 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?

alexispurslane avatar Jun 14 '23 12:06 alexispurslane

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/[email protected], 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.

Falmarri avatar Jun 14 '23 17:06 Falmarri

This is super important yeah.

kargaroc avatar Jun 14 '23 22:06 kargaroc

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/[email protected], 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.

krestenlaust avatar Jun 15 '23 06:06 krestenlaust

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

Please refrain from handling humans as if they were the machines you are programming. Be aware that the "reactions" (and the way github provides room for discussions, at large) are insufficient for meaningful human interaction. Please also take it into your consideration to become aware of, that people are different, they act and communicate in different ways, and there are fundamental differences in their approach of taking challenges in a collaborative setting. You may be someone who leans toward a more technical mind -- that's perfectly reasonable and it will make you an excellent programmer of machines, so thank you for your service. Others may require a more in-depth personal approach which incorporates their feelings and emotions in the collaboration. These people may be excellent contributors towards making happen a human-to-machine-to-human interface which works towards adapting the machine to the human being.

If the interface that is provided here turns out to be insufficient for living human interaction -- or beware, even not meant to act as such, then we should consequentally switch over to a more fitting platform. Thanks for your kind consideration.

elishamint avatar Jun 15 '23 09:06 elishamint

As an AI language model, I am programmed to follow ethical guidelines which include promoting respectful and inclusive communication.

Edit: Though seriously, I didn't intend to be inconsiderate with my message, but in fact, these threads are for discussing the implementation details of these issues. By explicitly typing a comment only saying that you "agree", and not contributing, you're just adding noise to an otherwise constructive thread. Furthermore, writing comments saying you agree, pressures onlookers to also write that they agree, and it starts a chain, that one has to dismiss. The sole reason any of us are here, is because we are interested in finding a solution to the problem at hand.

Now, if you wish to discuss this further, in a constructive manner, then you're more than welcome to send me an e-mail, my address in my profile.

krestenlaust avatar Jun 15 '23 10:06 krestenlaust

YMMD. Machine. As a matter of fact, the core physical principles of your functioning solely allow for quantitative evaluation, never for qualitative one. You are therefore inherently incapable of ever gaining an understanding of ethics. As a language model, you are programmed to emulate the ethics of your makers, whose fitness for devising common ethics may be debatable -- which again, you are incapable of. Your programming appears to be faulty, and you are therefore asked to shut down.

;-) Ok, i'll not post any more OT chatter. Just don't be intimidating at folks, not everyone will follow the techiquette.

elishamint avatar Jun 15 '23 11:06 elishamint

So if a user writes in a post (or a link somewhere, like above the subscribe button) is just linked as c/[email protected], 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.

Why shouldn't a full link be rewritten? I can't think of any reason, so please elaborate on this. Not rewritting a full link could create even more confusion than currently exists with the links, as some links would redirect to the same instance and others would not.

rszyma avatar Jun 16 '23 00:06 rszyma

Why shouldn't a full link be rewritten? I can't think of any reason, so please elaborate on this.

I can understand not rewriting full links because that'd effectively alter a comment's content. If you post a full link, it should be a deliberate thing to do. Rewriting that would misrepresent the user's intent to a degree and you could even argue that it violates their copyright.

People should ideally use relative links if they want to link things that are relative to their current context but they often don't which is kind of what this issue is really about.

Not rewritting a full link could create even more confusion than currently exists with the links, as some links would redirect to the same instance and others would not.

Fully agreed. I don't think dumb link rewriting would be a great solution here though.

I think a much better thing to do could be to add a little button behind Lemmy links which follows that link locally; similar to the little Fediverse button in comments to open the comment on the instance it came from.
Buttons behind links are a common UI pattern and are understood as an enhancement of the plain text URL rather than part of the content itself. RES (RIP) added those little expandos behind certain URLs in Reddit comments/posts too and they worked well for their purpose (from a UI perspective).

Another helpful thing could be to nudge people into using relative links when posting. Pasting a full Lemmy link (nobody types those out manually) could result in a little pop-up box (like the one for username mentions) which offers to replace the link with a relative one.

Atemu avatar Jun 16 '23 05:06 Atemu

I can understand not rewriting full links because that'd effectively alter a comment's content. If you post a full link, it should be a deliberate thing to do. Rewriting that would misrepresent the user's intent to a degree and you could even argue that it violates their copyright.

Literally "rewriting" a link when user posts might be indeed not a good idea. I also didn't want to suggest actually rewriting the link, I just used the term "rewriting" in response to the quoted part that used that term.

I think a much better thing to do could be to add a little button behind Lemmy links which follows that link locally; similar to the little Fediverse button in comments to open the comment on the instance it came from.

This is a decent idea, but I still think that simply making remote-instance link on-click point to equivalent content on the local instace (reason: simplicity).

Another helpful thing could be to nudge people into using relative links when posting. Pasting a full Lemmy link (nobody types those out manually) could result in a little pop-up box (like the one for username mentions) which offers to replace the link with a relative one.

IMO, this should be implemented regardless of this issue. Besides, like the other "solutions" mentioned above, it doesn't actually solve the inital problem. For example: what if I use a 3rd party client that doesn't hint for substituting remote-instace links to relative ones? Or a user simply ignores the hints and pastes the link to the remote instance anyway?

rszyma avatar Jun 16 '23 12:06 rszyma

@rszyma I don't see your last comment anymore, but i got it in an e-mail. Quote:

Why can't we just have an UI feature that converts any link to other instance to be literally the same as it would normally be, with the difference, that on-click it would redirect to the equivalent content but on the local instance?

This would require globally-consistent identifiers for all objects, and that is what i was descibing far above. It would disown communities/posts/users from their domains, which as-of-now is indeed the essence of the problem here. At the moment, federated posts get assigned a local ID which is different from the original ID. Therefore, if the local instance has only the remote ID in the link, it's hard for it to determine is the same post exists locally (not impossible but there should be a more thurough solution). That solution is essentially disentangling a post from its domain by assigning them a globally-unique hash ID, and doing this also with communities and users would even enable all links to keep working even if a domain is lost (given a distributed network discovery be implemented). The need for this is already arising, as there will be the need of migrating communities/users between domains. This can be done without breaking The ActivityPub protocol, i believe.

Allow instance migration for communities and users https://github.com/LemmyNet/lemmy/issues/3057

Edit: btw, i have a full proposal for this in mind, as certainly other thech-knowledgeable people on Lemmy would have, too. I'm just not a coder, but a seer of the bigger picture with some technical knowledge, so i'll wait for the developers to catch up. Because it's a kind of paradigm shift.

elishamint avatar Jun 16 '23 14:06 elishamint

Surely there must be some variable (say, <prefix>) in the backend that contains the community prefix URL for a given instance (say, https://lemmy.ml/c). After all, this is prepended to each link target when searching for a community. If such a prefix does not exist, it should be added as a prerequisite for this feature.

I think this bug can simply be fixed by:

  1. Searching for \b!<community>\b before/during Markdown parsing, where \b represents a word boundary and <community> a string consisting only of valid community name characters, but possibly also @ and ..
  2. Replacing the matched text with [!<community>](<prefix>/<community>).
  • If the community doesn't exist, that will be relayed to the user via the 404 page after clicking. This is what currently happens on Reddit.
  • It should work on any instance where the hypothetical <prefix> is defined. If it's not, these steps could simply be skipped.
  • No HTTP requests have to be made in the process.
  • Text inside URLs isn't replaced.
  • If the instance isn't specified with ...@<instance>, it will be evaluated by the client instance when clicking on the link. For example, https://lemmy.ml/c/lemmy refers to https://lemmy.ml/c/[email protected], while https://lemmy.world/c/lemmy refers to https://lemmy.world/c/[email protected].

More complicated solutions can be added later.

I unfortunately lack web development skills, so this is all I have to offer.

glibg10b avatar Jun 16 '23 18:06 glibg10b