Re: Remixing and Aggregating Task Force

Unlike Atom, RSS is completely inadequate as an aggregation format. That is
what motivated my own work on Atom's definition. I was then responsible for
PubSub.com, which was an aggregator and needed a standard that would allow
aggregation. While I could probably write many, many pages on the subject,
for an aggregator, the key difference between RSS and Atom is that Atom
entries are semantically independent of any containing feed. An Atom entry
can be distributed either as a single, independent object (or "document),
or within a feed containing many other entries. However, in RSS, this is
not the case, if only because in RSS order-within-feed has meaning. Also,
GUID (Globally unique ID)  is an optional field of an RSS item while in
Atom any "atom:entry elements MUST contain exactly one atom:id element."

You asked:

> if the items in the feeds keep their original IDs or if they get new IDs.


RSS is silent on the subject of changing GUIDs (even if present) when an
item is aggregated. On the other hand, Atom explicitly prohibits changing
the atom:id of an entry. RFC4278 <https://www.ietf.org/rfc/rfc4287.txt>,
which defines Atom, says:

> When an Atom Document [i.e. either a feed or entry] is relocated,
> migrated, syndicated,
>  republished, exported, or imported,
> * the content of its atom:id element MUST NOT change*.  Put another way,
> an atom:id element
>  pertains to all instantiations of a particular Atom entry or feed;
>  revisions retain the same content in their atom:id elements.  It is
>  suggested that the atom:id element be stored along with the
>  associated resource.


For the above, and several other reasons, RSS is completely unsuitable for
use as an aggregation format while Atom is explicitly designed to support
aggregation.

bob wyman




On Fri, Jun 6, 2025 at 4:11 PM Evan Prodromou <evan@prodromou.name> wrote:

> This is a great question! I actually don't remember how RSS or Atom handle
> aggregation -- for example, if the items in the feeds keep their original
> IDs or if they get new IDs. ISTR some strangeness around this.
>
> One work item for the group might be to investigate that topic and draw
> lessons from it.
>
> Evan
> On 2025-06-06 11:13 a.m., Bob Wyman wrote:
>
> How would ActivityPub/ActivityStreams aggregation be different from WebSub
> (PubSubHubbub)? If different, other than using json rather than Atom or
> RSS, why would it be different?
>
> bob wyman
>
> On Thu, Jun 5, 2025 at 2:43 PM Evan Prodromou <evan@prodromou.name> wrote:
>
>> We have a few projects in the Fediverse that are doing remixing and
>> aggregating content and other activities from other Actors. Two good
>> examples are Surf and Channel.org.
>>
>> I think this is an interesting enough pattern that we should open up a
>> Task Force at the SocialCG to investigate standardizing some of these
>> features. Important questions to ask are:
>>
>>    - How should an aggregated feed appear on the Fediverse? Is it just
>>    another Actor that Announces activities and content that meet its
>>    requirements? Or is there another structure?
>>    - How do we handle ordering of feeds? Some feeds might not be reverse
>>    chronologically ordered, but use some other algorithmic ordering.
>>    - How can feeds be transparent about what the sources are? Actors,
>>    search terms, hashtags, etc. What is coming into this feed? Can consumers
>>    inspect the sources?
>>    - Is the feed replicable elsewhere?
>>
>> Chairs, I'd like to propose an agenda item to discuss this possibility at
>> the next CG meeting.
>>
>> Evan
>>
>