indicate access restrictions/privacy information about a post and add implementer hints to respect them

[sknebel]

cf aaronpk/Quill#143 and https://chat.indieweb.org/dev/2022-02-28#t1646077696840800 based on some comments by @fluffy-critter

Clients (especially those that allow to post responses) should clearly indicate if a shown post is non-public and if responses are posted should direct those to be private too or at least clearly warn about them being public responses to a private post and that the user take necessary care to not reveal information. Similar concerns apply to generated reply contexts.

for this, clients need to be able to know that a post was private/access-restricted in the first place, so this needs to be exposed in the first place. This can be tricky depending on the specific implementations. Some ideas:

a) servers know if they used any authenticated method to fetch the feed content - but without extra info on the posts they can't tell if the post was restricted or not (if they fetch the post permalinks, they could try unauthed first and thus tell)

b) the concept of an audience as a property of a post has been about. If private posts mark this up, microsub readers can pass this through. There is little established about this though.

[fluffy-critter]

Yeah, there's definitely a multi-pronged approach which needs to be taken with regards to privacy. In some of my earliest private-posting musings I was suggesting adding some extensions to Atom (and would now recommend the same for mf2) to provide semantic markup indicating that there is post privacy at play, and also to provide visual affordances within the feed itself regarding privacy. For example, on my own site templates, private posts automatically have an 🔏 emoji added to the title, and feed contexts also add the following verbiage:

Note: This is a private entry, so please use discretion in linking to it or mentioning it publicly. Thanks!

In a microsub/micropub context it would be really helpful to have semantic markup which makes this clear and to provide an appropriate warning on the tool side as well. If there were markup like p-restricted or the like (and a related property for us Atom/RSS die-hards) that would, I think, cover the most common use cases.

Regarding idea b: I purposefully do not expose specific information about which audience has access to a post, though, as I just want the individual reader to know if they have access to it, not who else does.

[jalcine]

Would this be an opportunity to surface things like visibility and audience in how clients should work with a post? Granted, showing visibility could be an iteration of showing that lock icon and audience can be some sort of page that gives information to the client about who can see the associated content?

[dshanske]

This was referenced in the context of Ticket Auth https://chat.indieweb.org/dev/2022-07-04/1656956865899300