private posts refer to posts or portions of posts which are private to either the author or sometimes to a limited audience chosen or previously approved by the author (like close friends), the latter also known as a friends-only or protected post.
Typical silos offer some form of private posts (or messaging, like email).
Some silos offer some degree of friends-only posts.
This is a nascent area on the indieweb.
There are numerous use case for private posts, however here we are capturing use-cases raised by active Indieweb community members that wish to selfdogfood such features on their own site.
Allow silo friends to see private posts
From Tom Morris in IRC:
Allowing your Facebook friends to see things where you assume they *don't* have their own domain, and thus you'd need to support some form of Facebook-authentication to verify their identities before showing them the private post(s) you'd like them to see. "Similarly Twitter" friends.
Need to maintain an address book to coordinate identities across various silos, and allow users alternative authentication mechanisms (I'd be inclined to include email). Posts could be shared with individual address-book entries or predefined mailing-lists. Or dynamic lists like "Facebook friends", "Twitter friends" above, or as Aaron suggested, all the h-cards linked to from a webpage like chat-names --Kylewm.com 11:56, 8 May 2014 (PDT)
Tantek on IRC 2014-05-08:
interesting - I think tommorris was putting a bunch of thought into private posts - as he wants to do exactly that (with giving permissions to FB friends). re: address book - the minimal viable address book should be just a list of URLs of people in storage. On top of that, cache their full name and photo from their h-card at their URL (or retrieved by snowflake API from their silo profile URL). everything else should be retrieved dynamically from their personal site / profile URL. apply caching as needed. once you make your addressbook person-URL-centric, then all the permissions stuff becomes super obvious
- tl;dr summary: Use
WWW-Authenticateheaders and a new
<link rel>to signal to readers/subscription engines that there's a mechanism to get a bearer token to present for the subscription, and a subscriber can configure their feed reader to send said token with the request for the feed.
The IndieAuth Ticket Auth protocol provides a straightforward mechanism for publishers to safely provide authentication tokens to readers such that they can automatically receive private-post updates within their subscribed feeds.
We can learn from the UI that silos use to present and edit the privacy of posts.
- public (indexable)
- public (no robots / login required)
- friends of anyone person-tagged in the photo
- friends of the author of the photo
- subset of friends (curated whitelist) of the author of the photo
- only the author
When a post is shared with a specific list of friends, a small gear icon appears beside the status. Hovering over it shows a list of names who the post is shared with:
Clicking the icon shows a popover with more information and links to the friends' profiles:
The posts themselves do not have a "private" or not setting per se, but rather as a whole are the same as the privacy of the account. The time of post does not matter, e.g. posts that look private when an account is private are made public when an account is switched the public and vice versa.
You must be logged into Instagram to view private posts (posts from private accounts where you've requested access and they've granted access).
If you are not logged in, when you try to view a private post (e.g. by following a hyperlink to a private post permalink) you may see (as of 2017-01-22) a confusing message like:
Sorry, this page isn't available.
The link you followed may be broken, or the page may have been removed. Go back to Instagram.
On Swarm, people can checkin "off the grid", which shows the checkin only to the user themselves (with a lock-icon).
TODO: find a screenshot of Google+ posts shared publicly as well as with a circle.
Wordpress enables password protected posts Here's an example - note that it leaks the title and the URL. The password is 'indie'
LiveJournal / Dreamwidth
A classic example (and possibly the first): users are able to put their followers into specific friend groups who would have protected access to private posts. On LiveJournal this functionality was rather limited (IIRC, you could only set up one protection group unless you paid money) while on Dreamwidth all users have access to many access groups.
LiveJournal also by default provides you an access group of "friends," which included everyone you followed (the much-more-reasonable inverse of the "followers" group that Mastodon provides); Dreamwidth by default provides two groups, "friends" and "follows." — Dreamwidth's FAQ on the default group membership
- Note that my knowledge of LJ is based on having used it not-very-much ages ago, and seeing the interface now would require accepting an objectionable terms of service update. — fluffy
email, email lists
- private cc:/bcc: - author selected group
- private to a list server (listserv) - list maintainer selected group
- does any reader supports reading private posts?
Most of the current attempts at this have been trying to provide feeds that show different contents when fetched with some form of authentication. (e.g. server-indieauth). This is challenging for a number of reasons, and there haven't been many implementations at all yet. Maybe instead we could try a version of friends-only posts that works via WebSub delivery, avoiding the authenticated feed fetching problem entirely.
Private feed for each authenticated
Given that there is a private feed for each authenticated user on each website:
- How does private feed discovery work for readers?
- A "Follow me" or "subscribe" button usually only transfers the current URL to the reader, delegating the feed discovery task (which is necessary, since the feed reader might support one feed format but not the other). The reader will not be authenticated (as it does not have the same cookies or IP as the user), so it will not see the private feed.
- Does PuSH work with private feeds?
- Do you trust your PuSH hub enough to transmit private messages in its fat pings?
- The first two issues might be solvable through the ideas of Public Page Upgrading by upgrading the normal discoverable feed to a private one after authenticating. Kodfabrik.se 11:06, 24 February 2016 (PST)
- the feed can be public without the posts in in being public. Potentially the posts can be linked from the feed, though that may leak timestamp metadata (and content in slugs if you're not careful) Kevinmarks.com 11:10, 24 February 2016 (PST)
- There are also plenty of ways in which the feed URL might be inadvertently shared with others; for example, readers which provide Atom sharing feeds will echo the originating feed's URL in the item, including for public items. So a privileged reader sharing a public item will still expose their private feed URL. This is why I abandoned the idea of per-user feeds in my own work. Beesbuzz.biz (talk) 02:07, 29 June 2020 (PDT)
This requires a bit of thinking to see how we can make this possible with statically generated content (conversations in 2019/Amsterdam/privateposts)
Could be done client-side? Could be done with long URLs that aren't easy to guess/discover (https://indieweb.org/unlisted)?
Jamie Tanna has documented some options and a solution he is planning on building, in https://www.jvt.me/posts/2020/08/26/static-site-private-posts/
- When sending a private message, I don't want to write my contact's domain names but select the target contacts from a list. How can Micropub clients get a list of all contacts and contact groups?
- private account
- iceberg post
- https://github.com/tootsuite/mastodon/issues/712 - Mastodon issue regarding the challenge of a UI (and protocols!) for actually federating private posts (likely because no one has actually made it work, despite a few historical iterations of claims)
- 2010-07-21 Brett Slatkin: PubSubHubbub for Private Feeds (co-author of PubSubHubbub) may have some ideas worth exploring
- protected - the aspects in this (private page) that are actually about "protected" (shared with a few folks) posts/accounts need to be extracted and moved to the protected page.
- Use-case for keeping information of and about yourself, and even your posts online private, reducing the ability for for-pay impostors to impersonate you: https://connortumbleson.com/2022/09/19/someone-is-pretending-to-be-me/
- close friends
- Issue: name/naming and scope. It would be good to have different terms for actual “private posts” (one-party, visible only to you or whoever you allow to "act" as you, and maybe even not to some of them), “private messages” (two-party), “(password) protected posts” (n-party, visible only to who you give a password to), “friends-only posts” (n-party, visible to an already chosen set of friends (e.g. close friends) or family or both)