New Property: Audience

[EdwardHinkle]

Wiki Page: https://indieweb.org/Micropub-extensions#Audience
This is a proposed extension that allows a Micropub client to tell a server who should be able to access a private post based on a new property called audience.

[EdwardHinkle]

My server supports the audience property as an array of urls. My site has authentication code that checks the user's url when they are authenticated and if the user is trying to view a private post, if their url matches what was received in the audience property over Micropub, my site will present the post both on the permalink but also in my website's feeds.

I think this property is important to start brainstorming and experimenting with because in order to streamline the use of https://github.com/sknebel/AutoAuth as it's developed, we have to be able to communicate with the server to tell it who is able to see a given post.

[EdwardHinkle]

@sknebel I know you store a list of urls for people who can access private posts, do you use Micropub for this?

[EdwardHinkle]

@aaronpk I know you use audience to show the target audience of a public post. Do you feel like you would use the same mechanism for private posts? Or are there changes you would make when implementing private posts?

[EdwardHinkle]

@vipickering I see you were experimenting with an audience property in your post (https://vincentp.me/notes/2019/03/07/12-00/). Does your server support this property in your Micropub endpoint or just a backend storage thing? Have you considered private posts or just public ones?

[sknebel]

I don't use micropub for private posts yet.

[vipickering]

@EdwardHinkle Currently it's a storage thing, if the frontmatter is passed to the markdown file it outputs it. However it's minimal effort to add it in to the micropub endpoint, and it's on my "todo" list :-)

I don't support private posts, I don't think it's something I will persue. So all my work is public.

[EdwardHinkle]

Sounds good, thanks for letting us know @vipickering!

[jalcine]

I haven’t slated ‘audience’ as a field in v0.1.0 but it’s something for v1.0.0 of my site. My question now would be understanding the contents of the response. Is it a list of h-cards?

(Originally published at: https://v2.jacky.wtf/post/dc68e015-dc0e-4ca7-a4a3-b43d41621684)

[EdwardHinkle]

I think at it's simplest, it's an array of urls. URLs would of course, point to h-cards. That doesn't mean, one can't embed an h-card in the post similarly to how OwnYourSwarm embeds h-cards for checkins, even though the eventual best use case scenario for checkins is just sending the url of the venue.

[grantcodes]

Could audience not be a candidate to be prefixed with mp- as to me it seems more related to how the server should handle the post as opposed to the actual content of the post?

[EdwardHinkle]

That's a good question. To me, it seems the same as visibility, which so far has been discussed as a property rather than an mp- command. That said, I'm not completely sold on either implementation.

I do think the question exists whether audience should both be a property used for public posts (like @aaronpk, @vipickering and I) AND for private posts access control (like @sknebel and I use) or if they should end up being different properties. audience as a public post should definitely be a Micropub property because that absolutely IS content.

The real question is if the "private audience" which could be called audience or renamed something else should be a property. That said when someone accesses a private post on my website I DO display who has access to the post right now, so for me at least this is visible content on the post which seems to match a Micropub property rather than an mp-command. I am interested in other people's thoughts.

@grantcodes have you started to look into how your system will support private posts? do you currently support private posts?

[grantcodes]

@EdwardHinkle yes I agree it feels quite similar to visibility, and that to me could also be prefixed with mp- and still make sense.

I do have private posts, but they are private private 😄 and only for me, I can't see me using any sort of audience feature any time soon, just wanted to mention the mp- prefix as something to think about.

[EdwardHinkle]

Makes sense. Thanks for the input @grantcodes. Definitely an interesting thing to think about!

[EdwardHinkle]

Over in the visibility conversation, the idea of lists came up. Specifically this one: #11 (comment)

which shows how a list of people (represented by urls of h-cards) can have two different behaviors: if a post is private, the list of urls are people who can SEE the post (aka audience), but if a post is protected, the list of urls are people who are blocked from seeing the post (aka blocklist).

So one thing that will need to be determined through experimentation and feedback is: should these be two different lists or a single list?

[sebsel]

I want to point to the notes from this session at IWC Düsseldorf 2019 about private post UI. We talked about audience as a property too. You don't always want to share who is on the list, this could be information you want to hide. On the other hand, not all posts with an audience have to be private. The conclusion we came to, was that audience should be a different property than these blacklists or whitelists of the private posts. audience could be more of a display / indication of the intended audience, instead of an actual list of people.

Example of sharing to a group and being public: https://aaronparecki.com/2017/03/22/4/micropub-pr

At the moment, I derive this display version of audience from the (internal) list of allowed people. If I were to introduce audience, it would be a string (or maybe name + url / h-card), that I could set for a post, and then if it was not there, I would derive it like I do now.

Pseudo-code ahead:

audience = "Shared with " +
  if audience
    audience
  else if length_of(allow_list) > 1
    "you and others"
  else
    "only you"

I do realize that this is a totally different use of 'audience' than the rest of this issue is talking about, but I wanted to point out it is used already in this context too.

[EdwardHinkle]

Thanks for including this info!

This makes a lot of sense, so I think this proposed property should probably have a different name.

[grantcodes]

I might have a slightly different mindset to others but the way I would think of the audience property would be more like groups - e.g. google circles or facebook has a few options (friends only, friends of friends or public).

So in that scenario I could see audience being handled in a similar way to mp-syndicate-to where there server would send a list of audience groups that is has defined and then the client displays that to the user.

I think that could be interoperable with the idea of the audience being a defined list of people/urls. If the value matches the uid of one of your audience groups you use that, otherwise it is a individual url.

Using server defined groups like this would possibly also negate the need to block/allow lists, as it would be up to the server to define how the groups are handled.

[EdwardHinkle]

@grantcodes so that sounds similar to plans that I had. I currently have a Micropub query q=contacts which I could have sworn was documented on the wiki but seems to have disappeared.

So my plan was to use ?q=contacts to create an auto-suggest list or typeahead for selecting people to add to the audience/approvelist/blocklist. I had planned to incorporate my own custom groups into the contacts endpoint.

I do like how your idea sounds like more of a complete solution based on previous art (syndicate-to). I especially like the uid rather than a full h-card with u-url as the return. Really for something like this you only need a display name and an identifier, which can be a url or a random string.

I’ll have to experiment with this in Remark as I build it out as I already have the contacts endpoint that I can modify to fit this structure.

[EdwardHinkle]

I do think the issue @sebsel brought up remains. Even if you use groups like syndicate-to with uids, you probably don’t want to display the name of the group publicly. So if an audience attribute is meant as a public facing component, this feature should still probably be named something else. But we can adapt the name as we go from actual implementations.