Implement instance agnostic community linking

[nnhien]

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]

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

[nnhien]

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]

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]

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:

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

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

@dessalines @SleeplessOne1917

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

[Nutomic]

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]

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

[rszyma]

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]

This is superceded now by #1462