Feedback

What I mean is that all text is rendered as if it were all just one big clump of text, when the data contains multiple line breaks. One good example to see the problem happening: [https://standard-reader.app/a/did:plc:2cxgdrgtsmrbqnjkwyplmp43/mr38ns2d8hf9qzw5mt](https://standard-reader.app/a/did:plc:2cxgdrgtsmrbqnjkwyplmp43/mr38ns2d8hf9qzw5mt) By the way, Skyreader's Linkblogs are probably using markdown (quotes start with ">") inside the "plain text" element, but are also using some Leaflet elements in a weird mix. Another example to keep an eye on, so the change won't break it, as it contains Leaflet elements: [https://standard-reader.app/a/did:plc:4vjd3fe2cgzq5d24j4f3zvar/mq335ek37glr9ht30b](https://standard-reader.app/a/did:plc:4vjd3fe2cgzq5d24j4f3zvar/mq335ek37glr9ht30b)

Victoria·Jul 30, 2026

Open1

I was having a look at the developer docs and was trying to connect and make some requests based on a list of AtUri I have, to check if they were already bookmarked on my end and if not to bookmark them, and I ran into some issues, getting errors 500 back. Your published DID document (https://standard-reader.app/.well-known/did.json) has: {"id":"did:web:standard-reader:app", ...} Per the did:web method spec, a domain-root DID should preserve dots in the hostname — colons after the first segment are reserved for encoding path components (and %3A-encoded ports). As published, did:web:standard-reader:app decodes to a host named standard-reader with path segment app, not standard-reader.app — even though the document is actually hosted at the domain root of standard-reader.app. It should read did:web:standard-reader.app. Impact: This breaks the atproto-proxy integration path your own docs recommend (calling a user's PDS with atproto-proxy: did:web:standard-reader:app#standard_reader_appview). Confirmed via testing: - Calling getBookmarkStatus via atproto-proxy through a standards-compliant PDS, using your exact published DID, fails with HTTP 500 ({"error":"InternalServerError","message":"Internal Server Error"}). - The identical call, with the DID corrected to proper dot-form, fails the same way — consistent with your did:web resolution likely rejecting it too, since a resolver would fetch the real document and find its id field still says the colon form (a common anti-spoofing self-consistency check). - Calling the AppView directly with the same DPoP-authenticated token (bypassing the proxy header entirely) succeeds correctly and returns the expected response. So the proxy-header integration path currently appears unusable for any correctly-implemented PDS, not just unusual/self-hosted ones. Fixing the id field to did:web:standard-reader.app should resolve it. A workaround, already tested and working for me was to skip the atproto-proxy header entirely, and call Standard Reader directly — override the agent's base_uri to https://standard-reader.app just for those specific calls, keeping my normal DPoP auth (no proxy, no PDS forwarding involved). If there's another way around this and I was tackling it wrong, I'd be open to try it out too.

Mihai·Aug 10, 2026

Open0

I want to be able to only see posts in English

Standard Reader·Aug 10, 2026

Open3

I think a "Table of Contents" can be automatically added at the top of every article since it can be derived from the headers (h1–h6, or it's corresponding Markdown equivalent: # to ######). It should be collapsed by default: - In case there are spoilers - In case it's long 🖖🏽

Yohan Yukiya Sese Cuneta 사요한 謝雪矢·Aug 8, 2026

Open2

Option that exists alongside "Hide mirrored websites" that allows you to filter out any post made with brid.gy, for those who want a more vanilla ATmosphere experience

jacob·4 days ago

Open1

Maybe there can be an allowlist that can override the account-level and modlist-level blocks? We enter an account in the allowlist for those we want to see in Standard Reader, that way we can still see their blogging content but they remain blocked on the microblogging side.

Yohan Yukiya Sese Cuneta 사요한 謝雪矢·Aug 13, 2026

Open1

Currently, only Mochott have a "Series" feature. In Hugo (aka GoHugo static-site generator) they've had a Series too, separate from Categories and Tags. Basically, a Series allows an author to group articles that are part of series without the need to go back to the previous articles and manually update each with a new link to the latest article of the series. Maybe there's a way to support this in Standard Reader: Example: - Mochott series: [https://mochott.site/youronly.one/series/asean-national-flowers](https://mochott.site/youronly.one/series/asean-national-flowers) - PDS.ls: [https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.mochott.series/3msg6os3v7s2h](https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.mochott.series/3msg6os3v7s2h) If an article is part of a series, at least on Mochott page, a reader can see if it is Part N of X (at the top), and at the bottom there's a list of other articles in that Series. There is no method to add Series information to Standard.site, unfortunately, but I think it can be added if Standard.site is open to it. But for now, maybe it can be implemented per platform on top off their existing Standard.site implementation. 🖖🏽

Yohan Yukiya Sese Cuneta 사요한 謝雪矢·Aug 6, 2026

Open1

In rare cases, there are some keywords I would like to filter when Standard Reader displays a list of articles and publications. I think a keyword or semantic filter is useful to hide those results. **Keyword filtering** Personally, the publication name and description, and article title and description, are more than enough as basis. This way, if the keyword was mentioned in an article but it isn't the main topic, it won't get filtered. For example, I want to hide publications and articles with "politics" and/or "elections" and/or "president". But I don't want it to hide articles that mentioned "president" or publications about "presidents". **Semantic filtering** I think "semantic filtering" is the best way? So, if I add the keywords "politics", "elections", "president", the filter semantically connects them, thus, automatically doesn't filter any mention of "president" not related to politics and/or elections.

Yohan Yukiya Sese Cuneta 사요한 謝雪矢·Aug 6, 2026

Open1