Hi all!
So, I’m assuming everyone has seen links like https://beehaw.org/c/news and clicked through to find it doesn’t work right because it’s a different site (I’m assuming a different instance here).
Well, I just stumbled across an interesting feature: if you enter a link in the following format, it works for everyone regardless of instance of origin:
[News](/c/[email protected])
[My User](/u/[email protected])
You’re welcome!
The only problem is that if your instance doesn’t know about that community yet, it’ll just 404, you still have to search for it first because visiting the link doesn’t make your instance fetch the community yet.
This should still be the default behavior when it autofills a community link though, I hope they make this change 👍
Seeing the rampant confusion this causes when trying to subscribe to remote communities makes me wonder if the full community list could be shipped on initial federation, and community creation/change events could be eagerly shipped network-wide.
I get that in federated/peer-based systems you need to be choosy about eagerly propagating messages network-wide, but the list of extant communities seems like it would be fairly small even on a big server. Like hundreds would be common, and tens of thousands of communities on a big server could still compress down to a message-size of a few KB. Having the
/communities/
search and all-communities page do something useful from the moment of federation seems like it would reduce a lot of confusion.Or fetch it when a link is followed for the first time.
This does not work on Jerboa. In fact most instance/user/community link in Jerboa are just completely broken.
I’ll put up a github issue for it, maybe somebody can look at that
The devs have said they’d like to make this happen more automatically, but until then this is a great tip!
Sorry OP, but your links don’t work for me. Reading this on kbin and all your links are 404’ing.
Maybe you could bring it up with the Kbin devs? I’m sure it wouldn’t be too crazily difficult to have it work similarly over there. Just need to swap /c/ out for a /m/. Probably similar needed over here to translate /m/ to /c/ too.
This trick only works on Lemmy, because it relies on Lemmy’s URL structure. Kbin uses a different URL structure.
Removed by mod
There are an irksome number of ways to express a community:
- [email protected]
- https://lemmy.ml/c/lemmy
- /c/[email protected]
- Is that all of them?
The one that gets advertised in the sidebar is [email protected]. I’d love to see a canonical format established that has a superset of the useful behaviors of the non-canonical representations.
Edit: Most of those don’t get hotlinked automatically. Does a bang-prefixed link do anything useful (no it doesn’t)? And you pointed out c-prefixed does get hotlinked and work.
Edit2: As commenters below note, the behavior varies between web-ui and jerboa. 🤮
Can confirm bang-prefixed is broken, c-prefixed works. At least from the website UI.
https://lemmy.ml/c/lemmy is the only on that works for me on Jerboa. Even then it kicks me over to Firefox. Cc [email protected]
@lemmy
[@]lemmy[@]lemmy[.]mlIncidentally, this is how you’d find and follow it from, say, Mastodon or Calckey.
That is a really cool observation! It always bothered me that I couldn’t post after following a link/having to paste to search first.
This is a great feature! I wish this could work in the url field too, as I tried that, but it doesn’t take that much time to open the body of a post, so it’s not really a major issue to worry about though
Ahaa! effect. Yes of course, as URL handling within the browser will inset your domain automatically. (edit for clarity: web browsers assume a link with a missing domain to go to the same domain/IP as the page the link is on, that’s W3C standard – therefore facepalm).
So, there is a bug in that link-builder popup which comes up as i start to type a [email protected] link, right? It should not create links to the domains directly.edit: Unfortunately, links to federated posts and comments are still broken because posts synced to other instances get a different ID than the original. Same as with users, there is no unique post ID throughout the federation (no common namespace). Systemic error but probably simple to fix.
Going trough my old comments now. Shouldn’t be that much.