Bug reports, feature requests, and questions for Standard Reader. Feedback lives on userinput.app.
Bugs
5
Profile icon is not updated
Bug
My profile on Standard Reader is using my old profile picture, so the app is not keeping it synchronized, even though it's using the current profile picture on the sidebar.
[https://standard-reader.app/u/did:plc:fip3nyk6tjo3senpq4ei2cxw?tab=publications](https://standard-reader.app/u/did:plc:fip3nyk6tjo3senpq4ei2cxw?tab=publications)
The profile icon is also used for some publications of mine that have no icon, so they are using the old icon too.
- Pacotinho da Vic [https://pdsls.dev/at://did:plc:fip3nyk6tjo3senpq4ei2cxw/site.standard.publication/3mfx7fludyy3f](https://pdsls.dev/at://did:plc:fip3nyk6tjo3senpq4ei2cxw/site.standard.publication/3mfx7fludyy3f)
- Vic's mochott [https://pdsls.dev/at://did:plc:fip3nyk6tjo3senpq4ei2cxw/site.standard.publication/3mpu76mqdak24](https://pdsls.dev/at://did:plc:fip3nyk6tjo3senpq4ei2cxw/site.standard.publication/3mpu76mqdak24)
- Linkblog da Vic [https://pdsls.dev/at://did:plc:fip3nyk6tjo3senpq4ei2cxw/site.standard.publication/skyreader-links](https://pdsls.dev/at://did:plc:fip3nyk6tjo3senpq4ei2cxw/site.standard.publication/skyreader-links)
The general search is hard to find what I actually desire. For example, if I search by an article title I know "Making Feeds: Custom Logic Requests", the search results are terrible, because it's searching for each individual word and their variations, and ranking first any body text matches.
- The search should consider the article and publication titles as more relevant match.
- The search should also rank better complete matches for the whole string being searched, not pieces of it.
- The search shouldn't rank too high variables of the words I'm searching for (from the example I've used, I see multiple high ranking results just because they have "makes", "customized", "requested", or even "customers" inside their body text, that's not what I'm searching for, plus "customers" is not the same as "custom").
First Collection disappeared after setting up a new collection
Bug
First Series "The Spectrum" disappeared but exists on PDS:
- [https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.publication/3mptkqyimrkpv](https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.publication/3mptkqyimrkpv)
It disappeared after setting up a new Series "The Austronesian Philippines Digest" which is also in PDS:
- [https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.publication/3msv22g5gekmx](https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.publication/3msv22g5gekmx)
---
Even the First Issue "We are humans too" I recently published for "The Spectrum" can no longer see it, even though it's correct in the PDS:
- [https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.document/3msusovpjrkk3](https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.document/3msusovpjrkk3)
---
Tried so far:
1. Relog
2. Clear cache
I attached screenshots on what I'm seeing on my end.
Body text from Skyreader's Linkblogs is not including new lines
Bug
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)
did:web document at standard-reader.app breaks atproto-proxy interoperability
Bug
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.
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
🖖🏽
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.
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.
🖖🏽
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.
Takes time for new posts and edits to reflect since Jetstream v2?
Question
Just a question if it's the effect of moving to Jetstream v2 that new posts and edits takes time to show/reflect on Reader? I mean, similar to the previous issue where the system is still working on caching or indexing the source?
Update as of 2026-08-17 07:13 UTC
Example, was posted on 2026-08-16 15:55:37 UTC:
- [https://guhit.youronly.one/timor-leste-national-flowers-hibiscus-delonix](https://guhit.youronly.one/timor-leste-national-flowers-hibiscus-delonix)
- [https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.document/3mt7keunhsc2n](https://pds.ls/at://did:plc:bpotnohnlgcj3fbmp7ugx4en/site.standard.document/3mt7keunhsc2n)
