- 0 Posts
- 9 Comments
I’m talking about RSS auto-discovery via
<link>tags. In the head of the page there should be a link take like<link rel=alternate type="application/atom+xml" href="https://lemmy.ml/feeds/c/lemmy.xml?sort=Hot">. This way browsers, extensions, search engines and feed readers can discovery the link automatically without the user needing to identify the feed link on each site.
I must be blind. I opened a random community and couldn’t find anything that looked like a block button. I also searched for “block” and didn’t get any hits. I can only find the UX in my profile.
I used https://lemmy.ml/c/ckstechnologynews as an example.
Client-side hashing doesn’t really do much. It just makes your hashed password the effective password. The only advantage it provides is some defense against password reuse because the “source” password is hard to discover. However you shouldn’t be reusing passwords anyways so that shouldn’t matter.
An actual improvement would be using something a PAKE like SRP or OPAQUE. This way the server never learns enough information to authenticate as you.
A major downside of these systems is that because they aren’t natively supported by browsers they require javascript. But that probably isn’t a major issue because IIUC all interactivity on the webui requires JS anyways.
It would be nice if the RSS feeds were advertised. For example if I browse https://lemmy.ml/c/lemmy I wouldn’t know there was an RSS feed until I find and click the little RSS icon.
If a
<link>to the RSS feed was provided my browser extension would light up and I can subscript just by putting the community URL into my reader instead of having to spot the RSS button on the page.
It would be nice if there was a button on the community profile to make this easier to discover and use.
A common pattern here is making part of the URL human-readable but ignored. For example instead of https://lemmy.ml/post/112460/comment/110439 you have https://lemmy.ml/post/Lemmy-112460/comment/Lemmy-URLs-should-be-human-meaningful-110439. Everything except the numeric IDs is just stripped before hitting the API but makes it easier for a human to get an idea of what to expect.
There are a couple of minor downsides here:
- This can be used for phishing because the server ignores the text here. A malicious user can put something malicious.
- Can affect caching. I don’t think this is a major issue and can be resolve by redirecting all to the canonical URL. The redirect is cheep and the canonical URL can be cached.
This pattern is used on a number of sites such as Stack Overflow and Reddit and seems to work well.
I think it would make sense to keep cross-posts different threads. Different communities have different styles, norms and rules for the discussion.
However I think it would be amazing to have the option to:
- View all comments about a URL on one page.
- View all comments from my communities on one page.
Basically I think the underlying implementation should be kept as it currently is, but I think the UI could allow the user to visually merge these together when desired (maybe by default).
I think the main complication is that if you are viewing the merged view you need to decide which community to leave the comment on (or support cross-posting comments???) so it is a slight overhead for those who prefer to see things merged. But overall I think this would be a better solution.
Might be useful on mobile where anything but tapping is awkward. But personally I like that all links open in the same tab and I can middle click or ctrl-click to open in a new window. Makes everything consistent and gives the power to the user.