https://discuss.tchncs.de/comment/9436237
@MachineFab812@discuss.tchncs.de
(replaced with my own user profile, as I’m not trying to fill other users’ inboxes for no real reason)(also, this somehow worked right when making this post, but not the original comment)
[@MachineFab812@discuss.tchncs.de](/u/MachineFab812)
https://discuss.tchncs.de/comment/9293054 https://lemmy.dbzer0.com/comment/9620373
https://jlai.lu/comment/6487794
While we’re at it, am I missing at instance-agnostic method for linking posts as well?
No, I’m pretty sure that’s a quirk of how the fediverse works. Posts, comments, etc are in two places:
- the instance the community is hosted on
- your instance (i.e. unique to users of your instance)
You’ll want the first (the permalink) for general posting, and the second for your own use. However, lemmy doesn’t handle the first very well, so both options kinda suck.
I honestly don’t think there’s a good solution to this. We can make improvements though, such as lemmy figuring out that a link is a lemmy link, either through special syntax (like @user@instance or !community@instance) or checking a list of known instances, but the real problem is that users need to be aware of instances, and that’s poor UX imo.
I’m working on an alternative to lemmy that solves this (and has a bunch of other drawbacks that I hope are acceptable), but I hope it’s not necessary and someone more clever than me can solve it.
If the comments/posts were just numbered relative to their communities instead of generated by each instance, there wouldn’t have to be this disconnect at all.
/c/piracy.dbzer0.com/post/18177167
Would be THE instance-agnostic link for that post, and
/c/piracy.dbzer0.com/comment/9620373
THE instance-agnostic link for that comment.Don’t even have to redo how the instances generate content numbers for posts/comments generated locally, but set them to pull such numbers in for each post/comment mirrored from another instance. Not even slightly hard to come up with, though I don’t have my laptop with me so I’ll refrain from speaking one the difficulty of implimentation versus all the “legacy-numbered” content already out there.
Yeah, that would work within lemmy, and it would make it easier to detect whether a link is to lemmy or something else (look for /c/<community chars>@<hostname chars>/<rest>). But you’ll still have the issue of clicking a link elsewhere (say, a blog post) to an instance that’s not yours, so you still wouldn’t be able to directly comment w/o copy/pasting part of the URL to your instance.
That said, that change alone would reduce a lot of friction for users. My point is that it still doesn’t fix the root of the problem. I guess we could use a browser extension to auto-redirect to your instance of choice, but that’s just yet another barrier for users.
but set them to pull such numbers in for each post/comment mirrored from another instance.
I think the asynchronous way lemmy handles creating a comment/post and then sending it would make this difficult.
An entirely acceptable answer to both my original question and my suggestion, although I had already attempted to address that. Every instance generating their own, seemingly non-random*, numbers for every post and comment was a big reason my mind skipped to “insanity” for my title - can we say “does not, SHOULD not, scale” any louder? Thanks again.
*
spoiler
Looking at the comment links in the OP cross-referenced with entries on lemmyverse.net, discuss.tchncs.de and lemmy.dbzer0.com have similar user numbers, both an order of magnitude larger(as large? anyways…) than jlai.lu … the reason jlai.lu’s comment numbers has got so high, about one-half instead of one-tenth as the user numbers might suggest, probably boils down to those users being subscribed to a large number of communities, but still not so many as the users of the other two servers. Run that up against the fact that there are fewer communities than users, anywhere, et viola!
That concludes this episode of my conjectural bullshit. Thanks for watching.
It’d also be nice to have the community name in a link to a post or comment, just for general use.
This would still leave the problem of people not being able to just copy paste the url from an address bar. Re-learning how to link stuff is something some wont ever figure out. The relative linking of communities was a stopgap, and they break on kbin for obvious reasons.
Relative links aren’t an ideal solution anyway, as different clients handle things differently. A relative link that works in the default webUI, wont in photon, and vice versa (though photon already figures out links way better than the vanilla webUI does).
Not to mention that you’d still want to have absolute links work, too. Both within any client, and when opening links shared outside lemmy, and have them work in a way where you can interact from whatever account you have. By that point you may as well just figure out absolute links for everywhere.
Why would they copy-past from the address bar when every post and comment already has a button that copies the url to their clipboard for them?
Also, nothing I’ve suggested breaks absolute links. Hell, I’ve even been pointing out that I would like existing links to keep working, both absolute and relative.
Because they are used to that? Because that’s what the share button does in any browser?
I don’t understand why you are so combative.
You unaware there have been share buttons on posts/comments on most websites for years and years now? You already have to follow some sort of permalink button to get to a url that lets you share anything more specific than a top-level post, and that was the case in forums dating back to the ninetees.
You’re invoking a use-case that never was so narrow, nor mainstream as you’ve claimed. If people were actually so used to copying and pasting urls from the address bar, google and others would not be holding onto market dominance after all the things they have done to make the address bar in their browsers a pain to use.
Last, its not combative to address your comment point-for-point. I have not demeaned you or your logic, just called out where it was partial and incomplete.
In what way is my point invalid then? I think you are being combative, because you used the idea that people don’t copy urls directly, as if that meant there was a way to get relative ones working well. There isn’t.
People will use absolute links, so they should work. If they can be made to work, why do we need relative ones to solve the problem of links not opening locally?
Sure, when you use the various share buttons all over, you can get different more specific share options.
But when have they ever netted a relative link, much less done so when SHARING?
Generally, you’re right, except that Lemmy is a new use-case. Its like if facebook made you login again because you follwed a facebook.com link from within facebook, all because the user who created the link is in a different time-zone. What’s not to understand about how broken that would be?
An user following an absolute link that doesn’t re-direct them back to their own instance is likely not going to be able to interact with the content there. As things stand, we then have to search up the content we want to interact with on our own instance.
Within the context of a Lemmy user following a link from a comment, at least, the relative link is more useful. For a non-user reading such commente the desired behavior would be to open such links absolutely, pointed to the post’s orinating instance, the commentor’s originating instance, or the instance which is actually serving them that content in the moment, but hey, that’s the behavior we ALL get already, and no-one is proposing breaking it for non-users.
Fact is, Lemmy is already capable of serving up a different parsed url for logged-in users and non-users, the webUI just hasn’t implimented the feature yet, and so here we are.
here’s the tracked issue for “Instance agnostic links” https://github.com/LemmyNet/lemmy/issues/2987
Much appreciated.
@MachineFab812@discuss.tchncs.de When I type @ I get a user picker in the text interface that autocompletes the username, and then it just generates the link in Markdown. The link does not need to be generated in Markdown, just typing out that syntax will ping the user. The markdown is required, so users can click the link and view the person’s profile. That user will get a notification in their inbox.
Typing ! and then the name of the comm does a similar thing !piracy@lemmy.dbzer0.com. It will also format it in Markdown, but again, not required because that syntax will be changed into a localized link to the comm.
Localized comment links currently are not a thing, but it is an active discussion. You can view that discussion here: https://github.com/LemmyNet/lemmy/issues/2987 and the underlying issue that causes the lack of localized comment links here: https://github.com/LemmyNet/lemmy/issues/1101
Yes, that is the expected behavior, and what I attempted the first time in the link comment. I was surprised it wasn’t working, even after a page refresh.
Instances can themselves handle links agnostically, and clients are able to access that via the API.
Using the autocomplete in the webUI can mess things up, as it is from back when community mentions weren’t even turned clickable. The link is then an explicit markdown link to the user, and may not be correctly clickable in whatever client others are using, but may instead open an off-instance page in a new tab/browser app.
Even if you link to a post using its local url and ID, a client can, and some already do, open that link in-client from your instance. But this is something that still needs to become more widely implemented.
The “manual” way to open off-instance links locally is to enter their full source url into search on your instance, which should give you their local version as the sole result.
User mentions do not need to be links, same as communities. Just write
@username@instance.comand nearly all clients will correctly make it clickable, and Lemmy will also detect and notify the user about the mention.I don’t use any client besides the web-ui. There is no reason for the webui to not impiment obvious features found in multiple client apps, but yes, you’ve hit the nail on the head as to a desirable version of this behavior.
There is one big reason: it requires time and effort.
The vanilla web-UI is inferior to other clients in a variety of ways, and any feature requires that someone somewhere get it done.
You could make an endless list of things that are “no-brainer” features for someone to add, but the development still requires that someone somewhere go down that list, one item at a time.
For example, Lemmy only recently got the ability to show the real number of subscribers that communities have, instead of showing the number of subs from the instance you were looking at that community from. That’s nice, but each update can only come with a subset of the endless number of obvious improvements that could be made.
No client currently does everything that the Lemmy server can technically be made to do with the currently implemented API calls. But the solution to agnostic links already exists. Any instance, when handed the url to a post or comment, no matter what instance it is for, is able to turn that into the corresponding local url/ID, the work to make use of that to make all links work everywhere simply hasn’t been put in yet.
Not that long ago just mentioning communities and users was a pain, but that’s mostly solved now. Posts and comments will be too. Eventually.
You literally dismiss the necessity for any effort in your first paragraph and claim extentions/apps are somehow preferable, then in your last two paragraphs call out that the function is already present on the servers and the servers more feature-complete than the apps.
Pick a narrative. Letting the apps represent the more useful/enjoyable experience is a big reason the eventual API rugpull on reddit was such a shit-show. If your lesson-learned was “more app, more gooder”/“everyone should constantly reinvent the wheel in pursuit of fun and profit, so long as no one asks anything of the original devs”, you haven’t been paying attention.
When devs can no longer be bothered to impliment obvious features, its time to fork, not present a new compatability layer that you control as the solution. Its both a shitty user-experience, and an almost impossible path to fun and profit for any dev who has no control over the original code. Then you get dozens of others having to reinvent the wheel every time the original dev DOES impliment anything that breaks compatability with their apps, all in pursuit of dimes they will likely never see.
I, and most users, are here to participate in discussions, not promote the LateStageCapitalism rate-race for the next disposable-and-planned-obselecence-baked-in-to-its-very-nature digital widget.
Lemmy doesn’t have the development resources to Thanos snap itself into a feature-complete state overnight.
Forking would make that worse.
I can smell the entitlement of “when devs can’t be bothered to do the obvious” straight through my screen. We simply do not get to sit here and come up with things that are “so obvious they should be done already”. That’s not how reality works. The wheel didn’t exist until it was invented, and then built by someone.
I’m only explaining that the solution exists and is currently held by back by the fact that development isn’t done by materializing code into existence with an infinity gauntlet!
The fact that some client devs implement new API features before the vanilla webUI does (which btw is a separate thing from the lemmy server, and itself merely one client for it, albeit the default) isn’t unusual, or indicative of some massive fundamental problem in how the project is run.
Read up. I stated I would be refraining from speaking to the difficulty of implimentation as I do not have my laptop with me.
I’ve written apps/extentions for personal use. I would rather contribute to an existing code-base like Lemmy, but I acknowleged the fact I am in little position to do so, for the next two weeks in fact.
Entitlement, really? How is your passing the buck to extention/app devs different from my requesting a feature be implimented in the single location where it will stay fixed, saving time and effort for the devs, including for app and extention devs, going forward?
Where is your suggested solution that could be implimented, beyond suggesting that apps and extentions have this solved for their users, and we should leave it at that?
I’ve bought multiple such apps, and found the webUI preferable, so I’mma throw my future suggestions, requests, and yes, financial contributions, as well as any code I write if that turns out to be necessary on my part, at the single project that is already doing so many other things I’ve come to enjoy.
“What.”, you say.
…
Again. What?
I’m not passing the buck anywhere, I’m saying the lemmy server can do this but the default lemmy webUI doesn’t make use of it. At least not yet.
The problem isn’t being solved by the clients and apps. It’s solved by lemmy.
Some clients have just made use of it sooner than others, and the vanilla webUI is one of the ones that hasn’t yet. But the feature itself IS IN LEMMY ITSELF.
GOOD. Thanks for repeating what I thought I read you say the first time, only explicitly.
What.
One potential downside to this on the posts/comment front is that if the thread in question is not in a community your instance is federated with, any form of local redirect would yield just an empty post with no comments. Lenny’s current federation is primarily push driven, so when requesting a post from an unknown community will yield no historical comments, as your instance have never subscribed to the community and thus never received the push notifications. Whereas getting sent to the original instance, you’d be able to see the full interaction history and have a better picture of the intended discussion.
I don’t care about getting sent to the original instance per se. Getting sent to a landing page on the local instance that says "Hey, we aren’t federated with that instance, and/or no one on our instance has subscribed to that community. Here’s an externalized(http/url) link to the content you’ve attempted to access, with no guarantee it will work.
Understand that you may have to make an account with that instance or an instance federated with them if you wish to actually interact with this content."
how exactly would you propose that instance-agnostic links like this work? How should it behave, and how would you overcome the centralization, privacy, security, etc. concerns that it raises?
Because I can see a lot of different answers here and each have some unique challenges. But I agree, it is annoying to work around.
On android, there is this: https://android.izzysoft.de/repo/apk/dev.zwander.lemmyredirect
Which solves it from the client side
how exactly […]
Sure, UUIDs are a useful tool. What of it? If I put a UUID in a comment, it isn’t a link. This doesn’t answer my question or solve the problem. The link has to go somewhere on the web, or use a custom protocol specifier and be handled by a client application or something installed on the user’s machine. If you go the client app route, many/maybe even most people use lemmy in a browser at least some of the time, and this will never get the full adoption required to make it standard. If you go the web link route, then you have concerns like “who owns the domain/service that does the redirecting” (ie matrix.to), can they be trusted, how can they automatically tell which instance to send users to without privacy concerns?
If you’re proposing overhauling the whole architecture of lemmy to use consistent UUID-based IDs for comments, posts, etc. across all instances, that could probably work but there are some edge cases especially with malicious actors, and it would be a huge undertaking.
A better idea, IMO, is to let client apps/frontends handle the translation, so that regardless of what instance the comment is linked on, it is translated to the correct local link for local users (unless the instances aren’t federated), since there’s already the fedilink button to then see the post on the original user’s instance, but there are probably edge cases and performance issues I’m not thinking of/privy to, and its still a non-trivial fix, which is why it hasn’t happened yet. I’m sure the devs would welcome such a change if a PR were submitted with the kinks worked out, but it isn’t on their current priorities list afaik
If you’re proposing overhauling the whole architecture of lemmy to use consistent UUID-based IDs for comments, posts, etc. across all instances, that could probably work but there are some edge cases especially with malicious actors, and it would be a huge undertaking.
That was what I was suggesting yeah, version 3-5 look like it could work, you could use the originating server as the name-space, and a local server generated ID for the name. As long as they only use information sent elsewhere the hashes should be reproducible, so you can check that a server is only using it’s own name to send new comments/posts, which should protect against the obvious attacks.
The more I think about it I’m not sure you would even need to use an official UUID system actually, just make something like <originating server>-<id from origin server> as the unique ID?
I agree it would be a big change to make though, especially dealing with all the existing posts.
Why should I have to download an app to impliment an obvious feature that should just work in the web-UI? Lemmy is still in active developement, and there is no good reason to treat it like an immutable legacy code-base that should require external scripts and hacks in order to present and interact with properly.
My original version/thought?
If the comments/posts were just numbered relative to their communities instead of generated by each instance, there wouldn’t have to be this disconnect at all.
/c/piracy.dbzer0.com/post/18177167
Would be THE instance-agnostic link for that post, and
/c/piracy.dbzer0.com/comment/9620373
THE instance-agnostic link for that comment.We’re already using the LINK button on whichever post/comment to copy this stuff to our clipboards, so its not like there should be some massive concern over making people type too much. Url-shortening is also an option, but half the shortenned url’s I deal with any more are dead links - the page/original url isn’t gone, but the shortened version has been expired.
We wouldn’t even have to redo how the instances generate content numbers for posts/comments generated locally, but set them to pull such numbers in for each post/comment mirrored from another instance. Not even slightly hard to come up with, though I don’t have my laptop with me so I’ll refrain from speaking on the difficulty of implimentation versus all the “legacy-numbered” content already out there.
… seems like it would be easier to impliment without breaking most existing links versus UUIDs, BUT UUIDs are more of a standard, and either method would probably be best implimented with a server-side(or page-embedded and executed client-side) method for translating legacy links to the new version.
Why so hostile? I don’t see you contributing.
Anyhow, other users have provided context on where discussions are taking place on how to improve the issues you brought up. It’s not a static legacy codebase, but nor do ideas spring to life without dev effort.
Am OP. Presented one solution and lauded another. Meanwhile, you’ve poo-poo-ed both of those and suggested only an app or extention will do, while highlighting that the existing apps both already have the problem solved and aren’t necessarilly feature-complete versus the severs.
Your inability to pick a narrative or achnowlege the statements of others reeks of insincerity, and now you’re claiming I am not contributing to this thread I’ve started. Get lost.
Nope. I highlighted the app only because it’s an existing, working solution that an individual can use today. It is not a great solution for obvious reasons. I for one only browse via lemmy-ui, so that app does precisely nothing for me. My intention wasn’t to poo-poo possible solutions, but to push back on your entitled framing implying that it was such an easy problem that it must have been an intentional omission to leave it out. Other users had no problem conversing with me in good faith and not being so hostile. I agree it’s an issue, and so do the Lemmy devs, it just hasn’t been solved yet.
I don’t care about your contribution to the thread, I mean you aren’t contributing to Lemmy, the codebase, and so my patience for such a level of hostility and complaining is low.
You assume I’m not contributing … based on what? I addressed participation in this thread first as that’s the most convenient for me to substantiate. I’ve bought many of the clients, before trying them and finding I preferred the webUI, but I went into this more in my conversation here with @MentalEdge@sopuli.xyz … Regardless, I’ve stuck to the topic, except for where called out for “hostility”, “entitlement”, or “not contributing”. You went there first, and seem to have benefitted from the fact that my reply ended up on the wrong one of your (dismissive and condescending from the start)comments.
I don’t need your patience. This is not your post. Should have left you blocked, but blocking you obscured @RobotToaster@mander.xyz 's far more valid, one word, contribution to the topic at hand.
You assume I’m not contributing … based on what?
Based on the fact I haven’t seen your handle contribute to the github, which I follow relatively closely. Not to mention from your question’s phrasing, and lack of research beforehand, I could have surmised as much. A contributor probably would have been able to find the relevant discussion on the github and read it rather than just badmouthing the software in a post.
I agree, RobotToaster thought through their reply and came with ideas that might actually work, at least in their second comment, not just complaining “why isn’t this already the way I want it??”
Thing is, I know enough to come in here and ask “why not UUIDs?”, but instead I asked, yes, not far from the way you said it, but “why is it this way? Am I the crazy one here?” (the implication of “I think this is crazy and no one else does”, as sanity is generally defined by society or group concensus)
Funny story, I’m not crazy in this respect, this time, and the fix is already in the lower-level codebase even though the webUI hasn’t yet implimented it, or so I’m told, something that was more-or-less apparent from seeing it working basically the same across multiple clients.
It’s a little hard to contribute code from inside a moving(LOUDLY) steel box miles away from civilization, and I would have done some more research were I in a place to do so(contribute code, I mean, you know, best practices and all), but the idea that I would use this handle on github for non-machining related code is laughable, although you are correct on the specific criteria that I have contributed no code there whatsoever. I am well aware that I am more valuable here(not there, for now) as a shit-stirrer with a wallet, and see no reason to come at others with bUt dO YoU CoDe!?
