Specification Alignment & Element Placement for source Namespace

Open
#9 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
56/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript
Domain
backend

Research direction

Start by locating the feed-generation entry point that serializes channel and item elements, then inspect generated RSS for source:account, guid, and link. Verify that source:account is channel-level and that every micro-post has a usable item link or explicitly permalinked GUID; compare the output against the examples in this issue.

Written by the indexing model from the issue text.

Description

note: this issue description was generated by gemini.google.com

Context
This issue addresses feed validation, spec compliance, and subscriber parsing logic in the feeds currently generated by rss.chat (and downstream formatting via daverss). To ensure maximum interoperability with standard feed readers and future decentralized clients, we suggest two structural updates to the feed payload.

  1. Element Placement of source:account
    The Current Output: Under the current feed implementation, the item-level loop outputs the source:account element within individual blocks:

XML

<item>
  ...
  <source:account service="demo.rss.chat">dave</source:account>
</item>

The Conflict: According to the official Source Namespace Specification, source:account is explicitly defined and documented as a channel-level element meant to declare feed ownership.

The Solution:

If the goal is to attribute the author of an individual item in a mixed feed (such as the everyone feed or a multi-author thread comments feed), standard practice is to use the core RSS 2.0 element with its URL attribute pointing to the user's home feed:

XML

<source url="https://users.rss.network/dave/rss.xml">Dave Winer</source>

Keep source:account strictly at the level to specify the host-account of that particular feed.

  1. Micro-post Permalinks and Generation
    The Current Output: In the current rss.chat micro-post payload, items containing only untitled short text are outputting with a tag, but without a dedicated tag:

XML

<guid isPermaLink="false">https://demo.rss.chat/?id=1</guid>

The Conflict: Many desktop and mobile feed aggregators rely strictly on the tag to execute actions like "View Original Article" or "Open in Browser." When is omitted, these readers default to directing the user to the root homepage. For micro-posts, this forces the reader to manually scroll and hunt for a post on a reverse-chronological timeline.

The Solution: Ensure every micro-post has an active, targetable tag pointing to its specific permalink or a localized anchor. If the GUID itself is the permalink, ensure is explicitly set, or duplicate the URL into a proper element.

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scripting/rss.chat

All issues in scripting/rss.chat

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.