64°F

Aaron Parecki

  • Zegnat https://github.com/Zegnat   •   Feb 16

    Documenting from yesterday’s chat, because nobody could remember this and I can’t find it elsewhere:

    So I think the (as of now) latest proposed spec change would be:

    • p-name MUST NOT be implied if there are any explicit p-* or e-* properties, or any nested microformats.

    Currently all mf2 items have a name property, because of implied name. If we change this, some code using the parsers could fail if it assumes a name is present.

    Here too I will just document an answer given in chat, this time by @aaronpk:

    may just mean it has to be released as a major version number [of the parsers]

    Assuming something like semver is being used, any major version bump should signify possible API changes to the user. I too don’t think that would be an issue.

    There might be an issue if someone is using parsers-as-a-service, e.g. always getting their mf2 parser output from php.microformats.io. But I don’t think anyone ever advertised their online parsers as a service?

    Aaron Parecki

    I (and likely others) use xray.p3k.io as a service, so I will have to consider what to do in that case. It doesn't return the Microformats JSON, it converts it to its jf2 format first. I may just return an empty string for name if there is no mf2 name property.

    Portland, Oregon, USA
  • Aaron Parecki
    Great followup post!

    > I'd like to explore building a simple iOS application to remove any friction from posting updates on the go.

    If your site supports Micropub (https://www.w3.org/TR/micropub/), then you can use any number of Micropub apps to post to your site, instead of writing them yourself! In fact, there's already a fantastic start to an iOS app for exactly this purpose, called Indigenous, in beta right now. https://indieweb.org/Indigenous It should be a minimal amount of work to create a Micropub plugin for Drupal, and then you can take advantage of everyone else's work building clients!
    Portland, Oregon, USA
    #drupal
  • Aaron Parecki
    I just updated the text to hopefully be more explicit about this: https://indieweb.org/Microsub-spec#Set_Channel_Order
    Portland, Oregon, USA
    #microsub
  • Aaron Parecki

    No, that's not what I meant.

    Only the order of the channel IDs specified will be changed

    In your example 1, c has moved as well, even though only d and b were given.

    To move a channel up or down...

    This is equivalent to swapping two adjacent items.

    I didn't give an example of setting the order of three items because I couldn't think of a UI where it would make sense, but it is still possible.

    The nice thing about this approach is that the same update logic works for all the use cases, and doesn't matter how many items are in the list, and is atomic.

    Portland, Oregon, USA
    #microsub
  • jsorge https://micro.blog/jsorge   •   permalink

    @aaronpk @brentsimmons Thank you! Why would anyone put more than one feed on a page?

    Aaron Parecki
    I don't think they do, but gotta cover all the cases when you're writing code!
    Portland, Oregon • 41°F
  • Aaron Parecki
    Here's the current recommendation: https://indieweb.org/h-feed#multiple_h-feeds_in_the_same_page

    tl;dr: use only the first h-feed unless there is a fragment identifier on the second

    fwiw I haven't actually encountered this case in the wild yet when I was writing all my h-feed consuming code
    Portland, Oregon, USA
  • grantcodes https://github.com/grantcodes   •   Feb 13

    Working on implementing this in together now, I'm sure there is a valid reason, but I'm just wondering why the _id is different from the paging before and after values, could they not be the same?

    Aaron Parecki

    The before and after values are meant to represent pages of data, not necessarily individual records. In my case, the after value refers to an item that isn't in the current page. I could return a string for _id that looks more like the before and after strings, but that's just an implementation detail of my server. Alternately I may switch my before/after strings to look more like the current _id value. Either way, this difference doesn't seem important to the client.

    Portland, Oregon, USA
    #microsub
  • Aaron Parecki
    That would be an interesting feature that the microsub server could provide to clients. It does seem like this will always be a problem.
    Portland, Oregon, USA
    #microsub

  • Channel icons?

    I just added emoji in the channel names, and now I'm wondering if there should be a way to choose/upload an actual custom icon for channels.
    continue reading...
    #microsub
  • Aaron Parecki https://aaronparecki.com/   •   Feb 12
    I'm implementing a draft of this in Aperture right now. Here is the current API...
    Aaron Parecki
    I should add that the `_id` values are meant to be an identifier for this instance of the entry in the channel, not an identifier for the entry across channels. This means if you're following the same feed in multiple channels, entries may have a different `_id`.
    Portland, Oregon, USA
  • EdwardHinkle https://github.com/EdwardHinkle   •   Feb 12

    Not that it has to be implemented right now, but I do want to make a case for the “updated” field of a channel. In order to reduce “high noise signal”, for most of my channels, I’ll want the channel’s “unread indicator” to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying “there are new posts here” rather than saying “there are unread posts here”. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and haven’t read, while only being prompted to open the channel if there are new posts. The “new posts” indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I haven’t read (which is why this can’t just use the “last_read_entry”, even though that is a useful method).

    (Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)

    Aaron Parecki
    Here's a question. Do you imagine this additional state being something that only individual clients are aware of, or should that be synced to the server as well?

    If the server returns the "updated" date, then the client has enough information to show the indicator itself. But as far as other clients are concerned, they wouldn't know about whether you've seen those posts in another client.

    I'm kind of leaning towards it being a client-only thing, at least for now.

    If that's going to end up getting pushed to the server then I think we need to better define the different kinds of states. Maybe "read" vs "seen", where "seen" is the soft indicator that the client has displayed the post to the user, and "read" means they've opened it up (or maybe even explicitly marked it as read).
    Portland, Oregon, USA
    #microsub

  • Add option to remove entries when unfollowing a source

    When removing a source from a channel, Aperture provides an option in the UI to either remove all the existing entries or just stop adding new entries. It may be useful for this to be an option for Microsub clients as well.
    continue reading...
    #aperture #microsub
  • EdwardHinkle https://github.com/EdwardHinkle   •   Feb 12

    Not that it has to be implemented right now, but I do want to make a case for the “updated” field of a channel. In order to reduce “high noise signal”, for most of my channels, I’ll want the channel’s “unread indicator” to disappear when I reach the top of the timeline (even if things are unread). When a channel is updated (receives new posts), I would want to be able to re-enable the unread indicator. Essentially saying “there are new posts here” rather than saying “there are unread posts here”. In fact now that I say it, I might make the indicator a different color as well. That said, the purpose of such a channel is, I want to be able to know what I have and haven’t read, while only being prompted to open the channel if there are new posts. The “new posts” indicator essentially upping the priority of time looking at that channel than one without new posts. That said, when I have more time, to be able to go back to an existing channel and still know what I haven’t read (which is why this can’t just use the “last_read_entry”, even though that is a useful method).

    (Originally published at: https://eddiehinkle.com/2018/02/12/7/reply/)

    Aaron Parecki
    Now that you mention it, I think Facebook's notifications work this way.

    They show a little number over the notification icon with the number of new notifications. However, they also track whether you've clicked on individual notifications separately. If you click the icon with the number, then the number is cleared and won't show again until there is new content. If you click on an individual notification, then the next time you drop down the notification bar that notification will be white instead of blue.
    Portland, Oregon, USA
  • Aaron Parecki

    With the work in tracking read state, I've started implementing these additional properties by prefixing them with _. I felt like that was the least obtrusive way to include them while also making it obvious they are not part of the post vocabulary.

    Additional brainstorming around other per-item data should be discussed in new issues.

    Portland, Oregon, USA
  • Aaron Parecki

    The unread property has been documented in the spec, and implemented in Aperture.

    I am not sure the updated property is useful, so I'm leaving it out for now. I'm going to close this issue as most of the discussion is taking place in #4.

    Portland, Oregon, USA
  • Aaron Parecki
    This has been implemented in Aperture and documented in the spec: https://indieweb.org/Microsub-spec#Set_Channel_Order
    Portland, Oregon, USA
  • Aaron Parecki

    I'm implementing a draft of this in Aperture right now. Here is the current API.

    Every entry now includes a unique system ID, meant for internal identification of the item (not global identification). This is returned in the timeline response as the parameter _id, and there is now also _is_read. For example:

    {
  "items": [
    {
      "type": "entry",
      "url": "http://example.com/100",
      ...
      "_id": "41003",
      "_is_read": false
  ]
}

    These new _id values are meant to be opaque to clients, and must always be a string. Some servers will likely use integer database IDs, but other servers may use other string identifiers for entries depending on the implementation.

    Retrieving the list of channels now also includes the number of unread entries in the channel:

    {
  "channels": [
    {
      "uid": "notifications",
      "name": "Notifications",
      "unread": 0
    },
    {
      "uid": "YPGiUrZjNM36LNdpFy7eSzJE7o2aK82z",
      "name": "IndieWeb",
      "unread": 7
    }
  ]
}

    To mark an individual entry as read:

    • action=timeline
    • channel=example
    • method=mark_read
    • entry=1234

    To mark multiple entires as read:

    • action=timeline
    • channel=example
    • method=mark_read
    • entry[]=1234
    • entry[]=5678

    Both of the above also work with method=mark_unread.

    To mark an entry read as well as everything before it:

    • action=timeline
    • channel=example
    • method=mark_read
    • last_read_entry=1234

    This is to address the use case of streams, where you really only care about knowing where in the stream you've scrolled to and whether there are any new entries since then.

    This is mostly inspired by the Feedly Markers API Mark one or more articles as read and Mark a feed as read

    Portland, Oregon, USA
    1 reply
    #microsub #aperture
  • Aaron Parecki
    🤦‍♂️ Thanks. I think I'll add new channels to the top!
    Portland, Oregon, USA
  • Aaron Parecki
    Well that's not what I was expecting this issue to be about. Do you mean that you're going to run a server on behalf of the iOS client, so that you can send push notifications to it? I hadn't considered having Aperture send out WebSub notifications for content added to its channels, but that makes sense now that you mention it!
    Portland, Oregon, USA
    #aperture
  • Aaron Parecki

    Here is a diff of the changes.

    The main differences can be read here:

    Portland, Oregon, USA
    #microsub