Indicating Item Source

[aaronpk]

Because many traditional readers choose to show both the "Source" of an item in a feed when viewing it, in addition to the "Author" of the item, it may make sense to include some details about the Source in each Item in that source when retrieving a timeline.

See some examples below:

This will also be useful when someone reposts content, so you want the item to show the original author, but you also want to show who reposted it. Twitter does this by adding a line above the tweet.

[aaronpk]

A similar but slightly different version of this is when following content from forums, where you want to know which forum thread a post is from.

I currently use a forum API to subscribe to a few specific threads, which is sent to IRC. Replicating this in a reader interface would need some way to include which thread an item is part of so that it can be read in context.

[EdwardHinkle]

This is definitely important. Another use case, I have some news feeds that actually don't list the author. So I have "Unknown" as the author. I'd love in the event that the author is unknown and the source is known, to be able to just put the source in place of the author. Of course, if both are there then you can have both.

[aaronpk]

Would you want the client to do that logic of showing the source info in place of the author? It seems potentially messy to have the server do that.

[EdwardHinkle]

Oh, no the client can definitely do that. Just listing a reason why having source info was important.

[aaronpk]

Some brainstorming info:

It looks like current interfaces show the following information about the source:

• icon
• name
• url

Atom has the following properties in their top-level feed info:

• title
• link
• description
• copyright
• image

RSS has the following (abbreviated):

• title
• link
• description
• copyright
• image

It looks like an h-card would describe a source nicely.

All of the sources I'm following are either single-person blogs, so the source would be their name/photo, or multi-author blogs, so the source is the publisher organization.

[aaronpk]

My current thought for this is to add a new property to the entry with the source's h-card info:

{
  "type": "entry",
  "url": "https://example.com/1000",
  ...
  ...
  "_source": {
    "url": https://example.com/",
    "name": "Example Feed",
    "photo": "https://example.com/photo.jpg"
  }
}

My main question is whether the url should be the home page URL of the feed or the actual feed URL. I'm almost thinking we need to be able to include both.

If you're following an Atom/RSS/JSONfeed, then the feed URL is not something you'd want to send a user to, so you'd want the "home page" URL instead. For HTML feeds, it would be fine to use the feed URL directly.

However from a security perspective, if the entry's URL is on a different domain than the URL the entry was found on, the UI may want to indicate this in some way, similar to how my webmentions display the source URL as "via ____" if the source URL domain is different from the entry's reported URL. The main case this might happen is an aggregator where the every item in the feed is from a different domain than the aggregator's feed. Also micro.blog feeds where the post's original URL is reported instead of the micro.blog URL.

So I'm thinking we might need two properties, feed URL and home page URL. Unfortunately this no longer maps well to h-card. Any ideas?

[mblaney]

hey I hope you don't mind if I jump in here, I'm thinking I probably need to add microsub to my reader at some point, so might as well join the discussion....

I agree that each post needs to contain a source url, I'm wondering if there's a way to request the rest of the information you're after from the server? I notice there's a search option in the spec, but that's a bit too broad.

If the client could query a source url for all the options you've mentioned, it could apply them to any post with a matching source url. That would save duplicating the same information per post, and would simplify adding per-user editable fields like feed names as @sknebel suggested.

[alexmingoia]

I think we should preserve both source URL and author info, and stick to microformats. How about this?

{
  "type": "entry",
  "url": "https://example.com/1000",
  ...
  ...
  "_source": {
    "type": "feed",
    "url": "https://example.com/feed.xml",
    "author": {
      "type": "card",
      "url": https://example.com/",
      "name": "Example Feed",
      "photo": "https://example.com/photo.jpg"
    }
  }
}

In that scenario, I'd also suggest microsub servers to exclude the _source.author if it's the same as the entry author.

[aaronpk]

@mblaney Interesting idea on getting the source info in a different request. That does force clients to become a bit more stateful, as opposed to being able to render a timeline from only info that comes back in the timeline response. I'm imagining adding this to Monocle which doesn't store any info itself, so that would require adding caching or making more requests each time a timeline is viewed. I'm not sure where I actually fall on this idea, but just wanted to get that data point out there.

[mblaney]

@aaronpk yeah that makes sense. You could avoid the extra request by returning the feed level information with the timeline action. So instead of { "items": [], "paging": {} } it becomes { "items": [], "feeds": [], "paging": {} } where the feeds array only lists sources found in the returned items, instead of all feeds.

[EdwardHinkle]

Now that is interesting, because that starts to remind me of a jf2 style solution, where source is an id, and then the feeds array would contain the source data based on id? It would definitely help it be a single request and avoid duplication of data

[dshanske]

I want to propose source be provided as a required field and clients fall back on it when there is no author property in display, and can optionally display both. Author not being required as not always available

[jackjamieson2]

I strongly agree. And even when there is an item author, I often also want to see the publication. Not such an issue for single author blogs, but both source and author are significant information for feeds belonging to larger publications and multi author blogs

…

On Thu, Jun 20, 2019 at 1:05 PM David Shanske ***@***.***> wrote: I want to propose source be provided as a required field and clients fall back on it when there is no author property in display, and can optionally display both. Author not being required as not always available — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=AC5U5RYFFWM3HRPZBYHCW4DP3O2FNA5CNFSM4EOJ6XR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYGAYFY#issuecomment-504106007>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5U5R7Z56Y5BMAAJQP2V4DP3O2FNANCNFSM4EOJ6XRQ> .

[aaronpk]

{
  "type": "entry",
  "url": "https://example.com/1000",
  ...
  ...
  "_source": {
    "_id": "9857239874",
    "url": https://example.com/",
    "name": "Example Person",
    "photo": "https://example.com/photo.jpg"
  }
}

Properties:

• url, name, photo: display values, the client should show the name and photo and click on the URL
• _id: internal identifier for the reason this post is in this channel (e.g. the internal feed ID)

Clients should show an "unfollow" button next to a post, which can make an "unfollow" request passing the _id.

Commitments to implement:

Producers:

• Yarns
• Aperture
• Micro.blog

Consumers:

• Monocle

[pstuifzand]

Ekster has now implemented the format here for the items: #13 (comment)