Stable Property: visibility

[EdwardHinkle]

This discussion is around the proposed Micropub extension for a new property called visibility.

[EdwardHinkle]

This is the current discussion from the wiki entry:

As well as public or private there could also be use in a value to hide posts from a main feed. @grantcodes uses visibility=unlisted for this with his photo posts that appear in a gallery collection - The photos have their own post with a unique viewable url, but appear in a gallery post in the main feed, not as multiple individual photos. "unlisted" is [https://gist.github.com/joyeusenoelle/74f6e6c0f349651349a0df9ae4582969#how-do-privacy-settings-work already in use by mastodon].

@EdwardHinkle also uses unlisted as a visibility option on his server for posts that he doesn't want to appear in feeds, but he does want a publicly accessible URL for.

In addition to public/private visibility, Wordpress also supports password-protected posts. However, passwords are inherently insecure and also not very user friendly, and there are likely better solutions to the problem. Essentially the goal of password-protected posts on Wordpress is to provide "guest access" to posts, where the viewer does not need an account at the site. Flickr accomplishes this with something they call "guest passes".

[EdwardHinkle]

Another interesting value to think about in terms of visibility is "follower-only" posts. As described here: https://indieweb.org/private_posts#Sharing_only_with_approved_followers there is a simplicity is sharing a post with a general group of approved followers rather than always defining who can view every post. Is this something that would be useful to add to visibility? I can see how it could interoperate with AutoAuth, but this would also require a way for someone to "request to follow you". Is that worth investigating or is it best just to keep private posts with specific people who can see it (for example: #12: Audience)

[EdwardHinkle]

Also in another issue (#12 (comment)) @grantcodes brings up the idea that visibility might be a mp- server command rather an an actual Micropub Post property?

Any thoughts on that @aaronpk?

[jalcine]

A note: I don’t know if it’s okay to assume everything someone posts is public. This could be an implementation detail of the site but it should note that if no value is provided then it defaults to whatever the site determines to be the default visibility. What this is could be undefined or provided as part of ?q=config perhaps.

(Originally published at: https://v2.jacky.wtf/post/4fcf66ce-7226-44c2-814a-febac93598d4)

[EdwardHinkle]

@jalcine the reason it defaults to public is for backward compatibility because before this all Micropub posts were public.

At the core though, as you said, the Micropub server can really do whatever it wants to a post that comes in without a visibility property. It’s not needed to be in config because the Micropub Endpoint has final say. In fact, a Micropub Endpoint can override things as well. For example it could determine that all posts from a specific client should be private or unlisted

[grantcodes]

@jalcine I don't think anyone has said anything about public = default. The default option should be to not include a visibility property.

Having said that I imagine most micropub endpoints will handle no visibility the same as public, and if someone has a micropub server where no visibility does not mean public that's fine as the user will probably know how their site handles it.

And if clients expose a UI to set visibility there should be options of public, private, unlisted or not sending a visibility.

Edit: oops @EdwardHinkle commented at the same time.

But now I actually looked at the wiki... It says no visibility should be assumed public, but it's a should not must. Still think it's fine to do whatever you want if it's just for you. If it's for others just make them aware of the difference

[EdwardHinkle]

@grantcodes Yep, complete agreement! Only thing is as a Micropub client creator if and when my client supported visibility there would never be a “Don’t send visibility” option. It would just be public/private/unlisted. Once a Micropub Endpoint Supports visibility I think you should probably use it all the time.

You should probably be able to determine if a Endpoint Supports visibility though because if you as a client show visibility settings you need the Endpoint to agree to follow them or else the user will be VERY upset

[EdwardHinkle]

So this ties in with #8 that you should be able to get that visibility is a support property in the q=config. In fact, this is probably really needed if Micropub ends up being considered an evergreen spec like @aaronpk mentioned the other day

[grantcodes]

I'm not sure I agree with not having an option to not send visibility, I don't think there should be any property that should be used with every request, the server should handle defaults, not the client.

The way I have in clients is as a select element, with empty (with a placeholder) as default which sends nothing and then options with public / private etc. But in some clients I have a default that can't be changed, like a journal client that is always private or gallery photos that are always unlisted.

[EdwardHinkle]

I really don't think I would ever be comfortable NOT sending a visibility command in my app because for a non-technical user, a "unknown" visibility setting becomes mysterious and dangerous. We can't expect users to know if their server DEFAULTS non-obvious values to public or private.

If anything I think the server should be able to return a default setting for a property which actually gets into #8 territory, where I just wrote a comment... maybe my solution should also include a default value... I'll go add that.

EDIT: Okay, you can find my suggestion around default values here #8 (comment)

[EdwardHinkle]

Okay, after discussing in the IndieWeb chat between @aaronpk @grantcodes and myself, we came to this general consensus among ourselves:

• If a server supports visibility, it SHOULD communicate with the client what the default is.
• If a client supports visibility, it SHOULD send the visibility in the Micropub request, even if it is the default option.
• There will always be clients in the wild that don't support visibility, in those cases the server MUST default visibility to whatever it deems appropriate.

There is still some more to be worked out, but this is a good general approach.

[EdwardHinkle]

So I just started using visibility=protected this week to define posts that can be seen by anyone authenticated on my website.

The benefit of this is people have to have some form of prior connection with me (regardless of how they authenticate with my site). It also allows me to prevent specific people from seeing them if the person is in a global authentication block list on my site. Because of that I see protected as an IndieWeb equivalent of FB’s friends only

[dshanske]

I used protected as this term in location visibility(which has had limited implementations). In WordPress, protected means a post can only be viewed by someone who has edit permissions on it, but it isn't a post status. It is an attribute of a post status in WordPress.

I'd like to implement a protected visibility though, like @EdwardHinkle is. However, I would say that protected should be limited to all authenticated users by default, but can be paired with a secondary property to limit protection.

[sebsel]

I went for visibility: private for these posts, for now. Next to it I have another property which contains a list of people who can see the post: you need to be on the list to view it, but if the list is not present or empty, anyone can see it.

What I don't like about that, is that it gives you this weird inbalance, where the absence of the list means 'open to all'.

# illustration
{visibility: private, list: ['A']},  nil  -> 401, unauthorized
{visibility: private, list: ['A']},  'A'  -> 200, success
{visibility: private, list: ['B']},  'A'  -> 403, forbidden
{visibility: private},               'A'  -> 200, success   # this last one feels odd

I think I rather have a different value (like protected) for that last category, like you suggest. It's easier to assert that all private posts must have a list, and less chance of leaking something. I might change to protected.

[EdwardHinkle]

Thanks for the input @sebsel. I agree, that last one does feel a bit odd. The other thing that I think having protected opens up that I have found somewhat useful in the past is when a post is open to authenticated except exclusions (aka single post block list).

I haven't used it often, but in the past, I have found this setting on Facebook useful and thus, while I haven't found a specific use case on my website YET, if I did everything on my website that I use to do with Facebook, it would make sense that I would want thus functionality.

Essentially in this case

# illustration
{ visibility: private, approvelist: ['A']}, nil -> 401 unauthorized
{ visibility: private, approvelist: ['A']}, 'A' -> 200 success
{ visibility: private, approvelist: ['B']}, 'A' -> 403 forbidden
{ visibility: protected}, 'A' -> 200 success #Facebook's Friends Only
{ visibility: protected, blocklist: ['B']}, 'A' -> 200 success #Facebook's Friends Except B
{ visibility: protected, blocklist: ['A']}, 'A' -> 403 forbidden #Facebook's Friends Except A

the approvelist and blocklist could be named the same properties or could be different, just depends on the server. I named them different here for clarity.

[dshanske]

Private on my system is 404... doesn't even admit the post exists

[sebsel]

I would say the name of the list property is internal to the server, but unfortunately Micropub leaks some of that name, if we were to support editing the list via Micropub.

[EdwardHinkle]

I agree, the main point of showing the list above was to describe the different behaviors (approving people on private post or blocking people on a protected post). But I do think, as you said, while the internal storage name doesn't matter, if we support adjusting the names of people, Micropub will need to have a name for the lists.

I do think adding/editing the list of people will be important to have in Micropub if we want private posts to be as easy as Facebook. But as with most things, once the post gets to the server, it doesn't matter how the CMS stores it

Also, now that we're discussing the list, that brings up #12 which is really where the listing behavior lies. Because someone CAN support just doing standard public/unlisted/protected/private posts without dealing with any lists of people if someone wants, so I think that's the extent of this extension.

[EdwardHinkle]

So this is an interesting turn of events. In adding visibility to my Swift library, I realized both Public and Private are protected keywords in that language, which means I can't use them within the visibility enum.

For now, I've set up the visibility in IndieWebKit to have open and closed as the enum terms and those point to strings called public and private, so that when communicating with servers, it still sends and receives the strings public and private, but the enum still works with open and closed.

The big question though, is are there other languages that people use where they have to use a workaround like this? If so, we might need to pick different words for public/private. If not, my workaround will work just fine for Swift.

[sebsel]

I think there is a different property here, both audience and [something-]list can exist, which I discuss in more detail in a comment on #12 (comment).

Also, I would say the terms open and closed are less clear to me, esp. in combination with protected. I don't see this protected keyword problem in other languages I know... (PHP 7.0+ allows keywords as property, constant, and method names of classes, interfaces and traits, Ruby has symbols, Elixir has atoms, Javascript can have objects with properties named public, protected and private.)

I don't think we should take less descriptive names because of the implementation in certain languages. (You can also prefix your enum values like VisibilityPrivate, possibly? Lot's of options!)

[EdwardHinkle]

Absolutely, I don't think one language should effect the names of things, but having run into it I wanted to verify no one else saw potential language conflicts before we continued too far in implementing this.

[aaronpk]

I implemented this in Quill today. Quill queries the endpoint to find which visibility properties are supported out of public, unlisted, private, (more info). It then displays a dropdown to let the user choose from this list.

[dshanske]

As this is now stable, the discussion continues on which values are stable vs proposed.

[dshanske]

Closing issue, will keep this discussion referenced in the wiki page.