Implement instance agnostic community linking #1156

nnhien · 2023-06-10T18:52:20Z

Replaces the hyperlink component of the markdown link of the Tribute template with an instance agnostic way of linking to different communities.

For example, instead of autofilling ![email protected] to https://beehaw.org/c/technology, we should autofill it to /c/[email protected]. That way, we redirect users to the version of the linked community on their home instance. This makes moving around lemmy less jarring. Currently when someone whose home instance isn't beehaw clicks that link, they'll be "logged out" (even though they aren't "logged out"; they've just moved to a different website). This should be implemented because of the fact that all lemmy instances have the same UI, making what should be a pretty painless traversal kind of confusing.

I'm not sure how to spin up a local lemmy instance for testing frontend changes, so if someone could tell me how to spin one up or test this real quick for me, that would be much appreciated.

Also I'm not really acquainted with what convention the maintainers prefer for using existing types, but this seemed like the most straight forward solution. It's kind of inefficient though, since we don't use the CommunityView returned by the network response.

SleeplessOne1917 · 2023-06-10T21:15:48Z

I'll test this out locally when I get the chance. Otherwise, looks good.

nnhien · 2023-06-10T21:58:15Z

Hm wait, before this is pulled there I realized there might be a slight issue with the implementation.

While Lemmy UI uses the /c/ notation for denoting Lemmy communities, KBin uses /m/. I'm still not super familiar with how ActivityPub works, but if we just push the raw markdown and it gets pulled, this will cause interoperability issues with respect to linking. KBin does use the same [community_name]@[instance_domain] format after the /m/, but I'm currently not quite sure what the best way forward now would be if we want to preserve interoperability.

Since I'm not super familiar with how the standard is supposed to work, I think it's probably best to defer to the maintainers.

nnhien · 2023-06-11T03:38:59Z

After some thought, I have a proposal

We can formally (and unilaterally) establish a "Lemmy Community Linking Standard (tm)" with the format ![COMMUNITY_NAME]@[INSTANCE_DOMAIN]. We don't manually create a hyperlink reference in the comment content itself; the comment content simply has the above format. When a federated application's frontend encounters the above format and they have good support for Lemmy posts, they can convert the community link into a hyperlink which complies with how that application handles federated content.

What are people's thoughts

novakeith · 2023-06-11T06:05:02Z

After some thought, I have a proposal

We can formally (and unilaterally) establish a "Lemmy Community Linking Standard (tm)" with the format `![COMMUNITY_NAME]@[INSTANCE_DOMAIN]

What are people's thoughts

Two thoughts:

I did not see anything limiting how entities should be addressed in the ActivityPub standard. Hence why the devs probably chose to address Lemmy communities like this in the first place. If other softwares want to implement that standard, that would be great, and I think it should be encouraged for the reason outlined in my next point...
Kbin allows for the same community name as a user name, so you can end up with something like:

[email protected] (username)
[email protected] (community / "magazine" name)

Both are considered valid endpoints in kbin and there is no way to distinguish between the two. I think using the ! to distinguish community names is important, but its adoption outside of Lemmy is up to other devs.

Full disclosure. I am not a real software dev, I just like this project. Defer to dessalines and nutomic.

nnhien · 2023-06-12T15:51:35Z

@dessalines @SleeplessOne1917

Sorry for ping, but thoughts on this most recent kind of implementation?

dessalines · 2023-06-12T17:28:40Z

src/shared/utils.ts

@@ -700,7 +700,7 @@ export function setupTribute() {
        trigger: "!",
        selectTemplate: (item: any) => {
          const it: CommunityTribute = item.original;
-          return `[${it.key}](${it.view.community.actor_id})`;
+          return `${it.key}`;


I'm not a fan of this approach.

Instead, just have two links, the fedi one, and whatever you local instance is with the community.name.

IE something like [it.key](community.actor_id),[^local^](this_instance/c/community.name@community_instance.)

My worry with having two links is that it doesn't make the linking experience transparent. In my opinion, the user shouldn't need to know about the nuances of instances and how they interact in order to consume content. They should just be able to click a link and get sent to the version of the post on their home instance, especially since that feature is already built-in. That is, they should be able to get a single link and when they click it, things should should "just work".

Also, having the separate "local" link breaks interoperability with other fediverse services. The motivation behind my approach is that when a user posts, they just put text in a particular format. When that post gets fetched by other services (like Kbin), the other service can (or not) handle the formatted text in whichever manner they like.

They should just be able to click a link and get sent to the version of the post on their home instance,

Without the real community / actor links tho, there's a good chance that they won't even exist on your instance yet. We do this on all post and comment nodes, which have both their fedilink, and their local link.

Hmm, would it be a good idea to implement a companion solution to that issue then? That is, should we make it so that if you navigate to a post on a remote instance which hasn't been federated with your home instance yet, the home instance will automatically fetch the content from the remote instance instead of 404'ing? Or was there an explicit design choice to 404 instead of fetching?

This seems to be related to another common issue that people are having with interacting with remote instances, namely being able to discover communities on instances which their home instance hasn't encountered yet.

There aren't any 404s currently, because the post and comment nodes already exist on your own instance, or you wouldn't be seeing them (so neither link will 404).

But with searched content like this, the comment with text referencing a federated community or actor, might not exist everywhere.

the home instance will automatically fetch the content from the remote instance instead of 404'ing?

We don't currently do this, but this is the advantage of having a local link. We could do a resolveObject if it 404s, and cache it to our local instance. No guarantees still, since it could be blocked, but at least its possible.

We've chosen for resolve to only work on the search page currently, and by logged-in users only, but I'm open to a discussion for changing that. Def has pros and cons.

Another solution if we want to keep the explicit hyperlinks to different instances could be to implement a "You are leaving your home instance" screen before redirection. That way users are explicitly told that they are moving to a physically different website and they don't have to rely on vague UI clues to realize that.

But with searched content like this, the comment with text referencing a federated community or actor, might not exist everywhere.

I think we might be misunderstanding each other. In my mind, 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.

What I thought the problem was was that the local instance might not have the community cached, and so navigating to that link might not work. But testing it out myself has made me realize that any local instance can navigate to any community on any remote instance as long as the user knows exactly what the remote community name is and the remote instance domain is. So really what I thought was an issue is a non-issue.

Nutomic · 2023-06-12T22:07:59Z

This is a fundamental change which will affect lots of users. It would be better to discuss this more in an issue or directly on Lemmy before implementing any specific change.

nnhien · 2023-06-12T22:32:45Z

sgtm, found an already existing issue (#1048) so I guess discussion should be redirected there

rszyma · 2023-06-16T13:13:26Z

sgtm, found an already existing issue (#1048) so I guess discussion should be redirected there

While this PR is related to #1048 it doesn't completely solve the original issue that started #1048.

dessalines · 2023-08-04T20:37:37Z

This is superceded now by #1462

Implement instance agnostic community linking

a1da26a

nnhien requested review from dessalines and SleeplessOne1917 as code owners June 10, 2023 18:52

Handle edge case where "!" is in name

c17df1a

Nicholas Nhien and others added 2 commits June 12, 2023 08:50

Implement linking in an interoperable way

9913f5a

Merge branch 'main' into feature/instance_agnostic_community_linking

6d1d3d7

Nicholas Nhien added 3 commits June 12, 2023 08:53

Make separation between "render" and "handle" clearer

0b57f17

Handle edge case

adf9424

Use ===

2e4dabc

dessalines reviewed Jun 12, 2023

View reviewed changes

thegabriele97 mentioned this pull request Jun 22, 2023

Convert Lemmy and KBin community and user references into local instance links #1462

Merged

dessalines closed this Aug 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement instance agnostic community linking #1156

Implement instance agnostic community linking #1156

nnhien commented Jun 10, 2023 •

edited

Loading

SleeplessOne1917 commented Jun 10, 2023

nnhien commented Jun 10, 2023 •

edited

Loading

nnhien commented Jun 11, 2023 •

edited

Loading

novakeith commented Jun 11, 2023

nnhien commented Jun 12, 2023

dessalines Jun 12, 2023 •

edited

Loading

nnhien Jun 12, 2023 •

edited

Loading

dessalines Jun 12, 2023

nnhien Jun 12, 2023 •

edited

Loading

dessalines Jun 12, 2023

nnhien Jun 12, 2023

nnhien Jun 12, 2023 •

edited

Loading

Nutomic commented Jun 12, 2023

nnhien commented Jun 12, 2023

rszyma commented Jun 16, 2023

dessalines commented Aug 4, 2023

Implement instance agnostic community linking #1156

Implement instance agnostic community linking #1156

Conversation

nnhien commented Jun 10, 2023 • edited Loading

SleeplessOne1917 commented Jun 10, 2023

nnhien commented Jun 10, 2023 • edited Loading

nnhien commented Jun 11, 2023 • edited Loading

novakeith commented Jun 11, 2023

nnhien commented Jun 12, 2023

dessalines Jun 12, 2023 • edited Loading

Choose a reason for hiding this comment

nnhien Jun 12, 2023 • edited Loading

Choose a reason for hiding this comment

dessalines Jun 12, 2023

Choose a reason for hiding this comment

nnhien Jun 12, 2023 • edited Loading

Choose a reason for hiding this comment

dessalines Jun 12, 2023

Choose a reason for hiding this comment

nnhien Jun 12, 2023

Choose a reason for hiding this comment

nnhien Jun 12, 2023 • edited Loading

Choose a reason for hiding this comment

Nutomic commented Jun 12, 2023

nnhien commented Jun 12, 2023

rszyma commented Jun 16, 2023

dessalines commented Aug 4, 2023

nnhien commented Jun 10, 2023 •

edited

Loading

nnhien commented Jun 10, 2023 •

edited

Loading

nnhien commented Jun 11, 2023 •

edited

Loading

dessalines Jun 12, 2023 •

edited

Loading

nnhien Jun 12, 2023 •

edited

Loading

nnhien Jun 12, 2023 •

edited

Loading

nnhien Jun 12, 2023 •

edited

Loading