Add feed of origin to inReplyTo elements?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- javascript
- Domain
- backend-api-design
Research direction
No source files or tests are named. Start by reading the existing source:inReplyTo proposal and the repository's RSS 2.0 client and server handling; done requires agreement on whether and how an originating feed link should be represented, plus a defined implementation and test scope.
Written by the indexing model from the issue text.
Description
Hi there @scripting (et al) 👋 I'm loving all this activity around rss.chat 👌
I'm working on adding support for source:inReplyTo elements in HyperTexting (https://hypertexting.com) and it occurs to me that these elements could represent a new discovery surface for RSS clients if they carried a link to the feed the source:inReplyTo item originates from.
<source:inReplyTo xmlUrl='https://example.com/rss.xml'>https://example.com/2026/05/16/hello-world.html</source:inReplyTo>
NOTE: I don't have a strong opinion about the attribute name, so I used the OPML Subscription List
xmlUrlattribute name here as an example.
If I'm following the source:inReplyTo proposal correctly, source:inReplyTo elements should always point to an item in a feed, even if that item only has a GUID and not a permalink URL; in other words source:inReplyTo should never point to a URL that didn't originate from a feed (e.g. https://apple.com).
If that's true, traditional RSS reader clients that want to add support for source:inReplyTo elements could start by showing a link to open source:inReplyTo URLs in a browser (this sounds kinda clunky to me, but at least you're only one click away from the OP context), but they won't be able to do anything with source:inReplyTo elements that are isPermalink='false'. However, if source:inReplyTo elements carried a link to the originating feed, clients could fetch that feed in order to display non-permalink content (e.g. if the referenced GUID is still accessible in the feed); they could also display "follow" or "subscribe" buttons if the client is not already following the referenced feed. The latter would effectively introduce a new discovery surface for RSS which is pretty exciting!
- Dominant language
- JavaScript
- Stars
- 37
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from scripting/rss.chat
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
All issues in scripting/rss.chat
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
palladius/rails8-app-on-gcp#145 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
dotenvx/dotenv-vscode#139 ·
-
test-change-proposal
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
web-platform-tests/interop#1455 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
corsairdev/corsair#1764 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100