Read-only channels

[sebsel]

I am working on a Microsub server that, apart from the conventional 'feeds in a channel'-model, also uses channels to output filtered posts. For example: I have one channel that returns the most liked posts. The feeds that are used as input for this channel are in different channels.

A 'read-only channel' would be just like a normal channel, except:

• You cannot delete it. (But renaming seems fine to me.)
• You cannot follow anyone in it. (For the posts come from different channels.)
• You cannot unfollow anyone in it.
• You cannot get a list of followers.

In a way, the notifications channel is already such a channel, although it's never mentioned you cannot follow people in it. (Should you be able to?)

[sebsel]

It's up to the server to just not delete the channel if the user asks for it, but it would be better UI if the client would not show the delete button in this case.

[EdwardHinkle]

So this actually touches on some things discussed at IndieWebSummit '18 in regards to Micro.blog.
@manton talked about how if Micro.blog were to support Microsub, you shouldn't be able to delete (or rename) the channels provided by Micro.blog.

In fact, the description above also matches what I would imagine would exist in Microsub if Micro.blog provided the discover feeds and mention feed they would match this as well since you can't follow or unfollow people in the Micro.blog discover feeds.

Although in the main Timeline it would allow you to follow/unfollow people, so that part differs, but you still couldn't alter the main Timeline's name or delete it.

So I think it breaks these features into two areas:

• Can you alter the channel itself? (Rename, Delete, etc.). This seems to be centered more about permissions over a channel. This would apply to ALL of Micro.blog's channels (as well as the main Timeline) as well as the channels @sebsel is talking about here.

• Can you modify subscriptions on a channel (follow/unfollow/list followers, etc). In fact, this seems like this is a channel "type"? A collection channel versus a subscription channel? Not sure of the exact terminology, but something like that. This new "channel type" would match the notifications channel, the Micro.blog discover channels, mention channels and the channels @sebsel is mentioning here.

[manton]

Thanks @EdwardHinkle. Some of the discussion from IndieWeb Summit is captured in the notes here: https://indieweb.org/2018/microsub

I wonder what the best process is for officially moving these into the Microsub spec?

[EdwardHinkle]

@manton Do you currently return anything special to show that you have read only channels in Micro.blog or do you just return errors to certain modification changes that aren't supported?

[manton]

@EdwardHinkle Currently, neither. Some actions quietly fail. I don't think the idea of locked or read-only channels made it from the IndieWeb Summit session to the spec yet.

[EdwardHinkle]

Correct, it didn’t. I didn’t know if you did any experimenting on your own or not 🙂 sounds good. Hopefully we’ll get some of those ideas into the spec

[manton]

I don't want to add anything to Micro.blog until there's a proposal that gets a few informal 👍 from folks first. Off the top of my head, returning a readonly or locked from action=channels would probably be fine, but I could also see wanting a type as @EdwardHinkle suggested earlier.

[aaronpk]

I'm leaning towards a readonly property on channels. I think clearly communicating the intent of this property to app developers is important, and I'm worried that something like "type" could be misunderstood or confusing once you want to start adding multiple of these kinds of flags.

I'm not a huge fan of Boolean values in JSON though, so a different approach could be to add a new property like "modes" which is an array of short strings that define things like "readonly". For example

{
  "uid": "discover",
  "name": "Discover",
  "modes": ["readonly"]
}

This provides an easy extension point to add more modes. This also corresponds loosely to IRC channel modes.

One open question still is what exactly that readonly behavior describes. Seb listed a few actions that should definitely be blocked in these kinds of channels, but renaming the channel may still be allowed since it's really just a display name for that user. Is "readonly" too broad of a term? Should we instead describe in more detail which operations are disallowed?

[jackjamieson2]

I like the potential extensibility of a modes property, and I think a bit more granular set of properties than just 'readonly' could be useful. I'm thinking of creating channels that aggregate feed items based on a search term or post-type. Since these would be user-creatable, they should also be removable. (That said, since there's no mechanism for defining that kind of channel through the API, it might make sense to prevent deletion through the API as well, and leave them managed entirely through the Microsub Server's UI.)

[mblaney]

Just to offer a dissenting voice here, what's being described as special channels could also be done at the feed level. A server could offer these special feeds (ie aggregated likes, discover feeds, etc.) without dictating the channel settings. The server could create a channel for this special feed initially, which replicates what has been described already, but then allow the user to customise both the channel for the feed and the channel name, just like any other channel.

[EdwardHinkle]

@mblaney dissenting voice is always helpful. 🙂 but in this regard there are two types of things: a Microsub server that provides special feeds or channels but there are also services like Micro.blog that will support Microsub with their own services. So knowing Micro.blog has a need to be able to lock down channels, I think it makes sense to keep this permissions stuff at the channel level.

@aaronpk I like the modes array. It allows for extensibility like I was hoping with the “types” but I think it’s even more flexible because a type would only be a single type but modes allows for the combination or various modes as time goes on.

This might make it too complicated but I wonder if we could treat it like OAuth 2 scopes, so readonly would lock down the entire channel where as readonly:rename or readonly:follow could define the sub areas that are locked down? Again, because of the array nature of the modes, it could work similarly like scopes where you could have [‘readonly:delete’, ‘readonly:rename’] to prevent deletion or renaming but to allow following (this would match the functionality of Micro.blog Timeline Channel), where other channels could just be [‘readonly’] and that would be like a standard notifications channel as well as Micro.blog’s mentions and discover feeds.

The term readonly feels a little clunky in the scope type thing, but it’s just an example, I’m not tied to any terminology. Just curious about the scope-like approach.

[sebsel]

Yes, readonly feels like the wrong term to me now too, although I don't have a better name now. I like the idea of modes, but I think the whole scopes with colons could be a bit complicated.

It is also the question of: do you list the permissions or the denials? "modes": ["deletable"] or "prevent": ["delete", "follow"] or "modes": ["no-delete"]. (And in the last case: is that no-delete of the channel or no-delete for the entries in it?)

As for doing this at the feed level... I like the idea of keeping the channel layer simple. At first it seems like Micro.blog has a valid use case. Wouldn't it be confusing to the user? "Please log into this reader, then add channels and by the way, also follow this magic feed to see curated posts."
On the other hand: Micro.blog could just set it up like that when the user first logs in, and leave the user up to decide. I might like that more: you get control over whether or not you want to follow these special streams of posts.

Edit: this actually might solve my use-case more than it does Micro.blog's, now that I'm re-reading it, but unforunately I'm out of time to think it through at the moment. Will revisit.

[manton]

To be clear on the Micro.blog case, these special channels cannot be deleted or renamed. The user doesn't get a choice because the channels are a core part of the interface.

I like modes but think it should be kept as simple as possible without the scopes. To start with: readonly (the feeds in the channel are set and cannot be modified) and locked (the channel itself cannot be deleted or renamed). I'd be happy with a single mode that meant both of these things, but it seems like some services might want readonly while still letting the user delete or rename the channel.

I'd be fine with more explicit permissions like @sebsel suggests as well. They should be what isn't possible, though, because an empty modes list should mean "full access".

We should also make sure that modes works for the notifications channel. Even though the spec documents that the notifications channel cannot be deleted, servers could return the appropriate modes for it as well.

[aaronpk]

Agreed that empty/missing modes should mean full access.

There's one more question for micro.blog here. Right now, Monocle has a UI to let people remove posts from a channel. This is so that people can always hide posts that they don't want to see for whatever reason. Is that something you also want to prevent people from doing in micro.blog? If so, is that a separate permission, or is it part of readonly or locked?

[manton]

I think readonly could also prevent removing posts. Splitting out the permissions any further doesn't seem necessary unless there is a real implementation out there that needs it. To me, readonly means the contents of the channel can't be modified, whether that's adding feeds, removing posts, etc.

[kaleb]

Perhaps an array of capabilities or an array of capabilities not supported for a given channel.

[jalcine]

This might be weird, but I think for Lighthouse, I'm going to aim to implement the modes to reflect what actions more explicitly that mirror the actions with a prefix noting if it's been explicitly removed or added. This would be expanding what Aaron mentioned about IRC modes.

For example, the following would inform that no entries can be removed from this timeline, it can adjust the read status of entries and people can be blocked—a common use case if you're blocking someone in your notifications for example:

{
  "uid": "discover",
  "name": "Discover",
  "modes": ["+block", "-timeline", "+timeline:mark-read", "+timeline:mark-unread", "-channel:order"]
}

To note, the operations are scoped by 'nouns' because my implementation does that to group actions. It doesn't have to be like the above:

{
  "uid": "discover",
  "name": "Discover",
  "modes": ["+block", "-follow", "-unfollow", "+mark-read", "+mark-unread", "-order"]
}

(Originally published at: https://jacky.wtf/2022/4/-i/-i306Mt2LwlYDzSIc1KEFC6C)

[jalcine]

I think the approach I mentioned allows for more adaptive descriptions of services and clients, but allows granularity when it's needed. This is important to me because I want to be able to provide an anonymous view in my Microsub server, so things can be viewed but not acted upon. The client will be able to view a timeline when not authenticated, but the channel would be decorated with modes hinting to its capabilities to make it clear that this is a “read only” lens.

(Originally published at: https://jacky.wtf/2022/4/8S/8S3xtz6DTl8_I6THHGCfRPlD)