Aaron Parecki

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?

The majority of the use of this gem is for sending webmentions from sites that use h-entry, since it's expected that the receiver will go parse the page and find the h-entry on the sending site. Without the filter of only finding links inside the h-entry, this gem would end up sending a bunch of webmentions to pages such as links in navigation or the site footer, which is usually not the desired result.

I pushed an update to Aperture which allows you to toggle per-channel whether read state tracking is enabled. There are two modes, one where it returns the count of the number of unread items, and the other where it returns only true or false depending on whether there are new items.

For my super busy feeds, it wasn't useful having the counts, but I do like a subtle indicator there are new posts.

There are also some channels I don't want to be bothered about at all, so I've disabled read state tracking on those.

This means the Microsub API is now returning either an integer or a boolean for the unread property on channels, e.g.:

{
  "channels": [
    {
      "uid": "notifications",
      "name": "Notifications",
      "unread": 0
    },
    {
      "uid": "31eccfe322d6c48c50dea2c84efc74ff",
      "name": "IndieWeb"
      "unread": true
    }
  ]
}

This has been bugging me as well. I have Instagram as a channel, and there are almost always new photos there, so the unread count is pretty much meaningless.

I was also thinking of a third option which is to only track whether or not there are new posts, not the number of new posts. This could show up in the API as unread: true rather than unread: 24.

Can you provide examples of what you're finding that is not normalized?

Microsub is not "merely delivering the content from other locations". Microsub is in fact specifically already doing a lot of normalization of the content it finds, producing a feed that is much more standardized than what it discovered when crawling the feeds, even to the point of making vocabulary-specific decisions about some values.

Hi Nitin, this sounds like a recent change to the way Known handles IndieAuth to make it return the root URL for single-user sites, which it should have been doing all along. There are a few ways to fix this for your Compass, all of which will require that you can modify stuff in the Compass MySQL database.

Method 1:

• First identify the Compass database in that has your data in the databases table. If you've only created one Compass database there will be only one record. Make a note of that id.
• You should see two records in the users table, one for https://nitinkhanna.withknown.com/profile/nitinkhanna and the other for https://nitinkhanna.withknown.com/
• Make a note of the id for each.
• In the database_users table, you should see one record with the database_id of your previously found database, and it will have one of the user IDs associated with it. Add a record for the other user ID.
• That will grant your new profile URL access to your existing Compass database.

Method 2:

• In the users table, delete the record for the new IndieAuth URL https://nitinkhanna.withknown.com/.
• Change the url of the other record from https://nitinkhanna.withknown.com/profile/nitinkhanna to https://nitinkhanna.withknown.com/.
• Now when you log back in your new IndieAuth URL should match up with the user record.

Hope this helps!