casutherland
commented
4 years ago Additionally, for team blogs
A/ One blog would automatically exist for every user, team, and perhaps for each team.user.
B/ In the future, for team blogs, it might be desirable to have a configurable ACL to control which team members may post to the team blog, and what visibility restrictions may be specified for new posts created by the team (team-visible only, external parties may be specified, or world-visible).
As a keybase user, I would like to post blog entries to a personal top-level blog that would only be visible within the keybase client app.
The posts would be in markdown format, lengthier than tweets or chat messages, but not novel-length. Embedded or linked media/images and attachments could be served from my keybase public shared folder.
The visibility for posts would be either 1/ key-signed, but not encrypted, public blog posts (visible to any keybase user), or 2/ encrypted blog posts (only visible to an ad-hoc list of individuals or teams, specified on a per-post basis).
Furthermore, it might be nice if I could grant retroactive access to a stream of encrypted non-public blog posts tagged with a specific #hashtag. e.g., grant \@susan access to all of my #secretbbqrecipe blog posts, past and future.
The killer application is personal blogging, with selective visibility for each blog post or #topic.
Further review is required of cryptographic limitations and challenges for larger ad-hoc lists of individuals and teams, however it seems that with the keybase platform we could be in a position to solve this problem.
The blog feature could potentially be built on top of the keybase public/private file sharing sub-system. Or, the implementation could potentially resemble a # blog chat channel, with special visibility controls (default visibility and ad-hoc per-post visibility controls).