5 ms·

some quick thoughts/notes (I am on the bluesky team, but this isn't an official policy statement): - content on bluesky is public, but we have not set expectat

some quick thoughts/notes (I am on the bluesky team, but this isn't an official policy statement): - content on bluesky is public, but we have not set expectations/comms around that well yet, and this dump may be a surprise to some existing accounts. where exactly bluesky falls on the spectrum from "congressional register (immutable)" to "public web" to "public IRC or discord room" to "private signal group" is still being worked out, but probably closest to "public web" - the protocol supports both "deletions" (retaining history), and "purge" (aka "rebase") to remove all not-current content. this isn't exposed via UI yet and accounts have not had the chance to purge old deletions - the federation protocol and unified firehose should make it possible for third parties to maintain a live mirror of the entire corpus. importantly, it will be easy (or at least "easier") to respect intents w/r/t deletions when done this way, compared to dumps - obviously neither "deletion" nor "purge" can perfectly remove content from 3rd party dumps and infra, or from hostile parties. but it does signal user intent clearly, and we expect as a norm that third parties will respect that intent. ADS-B, robots.txt, CC licensing are related to these norms, though all unique. right-to-be-forgotten, archiving, re-use licensing, use in ML training, commercial/non-profit reuse, search indexing, etc, are all on our radar - blobs/images are not included in this corpus - this specific corpus does not (I assume) include our important "label" moderation metadata. at least for our (Bluesky) core moderation decisions, that information will be public - private/group content is not yet part of protocol. eg, no built-in mechanism for DMs or follower-only posts. we will probably do those eventually, but it will be basically a whole separate protocol, not a bolt-on to existing stuff. wildly different privacy/security concerns with non-public content - there are some other cool projects, like https://bsky.jazco.dev/ https://bsky.jazco.dev/, working with the full social graph, pulled via public API

brundolf 3y ago
Thanks for weighing in It's disappointing to hear that follower-only/circles (whitelisted viewers) posts are basically incompatible with the current protocol. I'd hoped something could be done where the post content was encrypted in such a way that only specific authenticated users could decrypt it, or something along those lines
- capableweb 3y ago
  It doesn't sound too hard to layer on top of AT Proto. You already have cryptographic building blocks so you can encrypt content for specific users, I'd guess the only thing that is missing having something like that is the actual UI. But I haven't done a deep-dive into the protocol, just a surface glance so far.
- afiori 3y ago
  From what I gather it looks like this feature would not be a good fit for the current architecture.
areoform 3y ago
As a team member, one request that I do have is that don't make Clubhouse's mistake. Someone once told me that Clubhouse was like a house party, where your behavior reflected on who invited you. So it kept the initial community quality high. The minute Clubhouse removed that invite-only policy, the community died very quickly and everything was replaced by the worst sludge imaginable. I think you should keep the invite structure, and increase the number of invites to positive users/communities (as you already do!). And use the graph that naturally forms to inform content moderation. Social shame is a strong motivator that hasn't been properly deployed by a platform yet (mobs on twitter don't count). What I'm thinking about is that if someone you invited directly does something horrible like, posts slurs to a user, then the inviter should also get a notice that their invitee was a horrible human being. And if this inviter's invites end up being toxic people, then it may be a good idea to prune that branch of the tree. This structure will limit growth, necessarily, but it will also give you time to solidify a new kind of structure and a new kind of experiment in social media. I think it is possible to have a high-quality social network that scales. Also, please for the love of god, I want to get my mom to use the platform, can you make sure that stuff doesn't break containment?
- thealchemistdev 3y ago
  Social solutions to social problems. Perfect!
  - marvin 3y ago
    Not perfect. Brings the problems of social solutions too. Popularity contests, smooching, people & groups ostracized for status game reasons, other forms of social bullying and so on. It’s maybe great for a frat, but it will struggle for exploring the fallow lands close to controversial topics. This happens to be where a lot of the really important stuff happens, the explorations that lead to growth. You can’t solve this by simple weighting. Most novel true and important things are only realized by a tiny minoroty. And if they happen to be unpopular, forget about it. If the purpose of your social network is to be actually useful for the world, this is an extremely important feature
verdverm 3y ago
How do you intend to prevent someone from manipulating their mirror? Are users signing their messages before publishing to a data server? It is unclear from the documentation.
- bnewbold 3y ago
  all public account content is in a "repo", commits to the repo are signed, and the identity resolution mechanism gives anybody the current/active signing key. the most direct analogy is to signed git commits. this is an intentional design decision compared to signing individual messages/posts/etc. A "proof" for a single record in the repo is the commit, the record, and the chain of merkle tree nodes connecting the two.
  - verdverm 3y ago
    Who signs new nodes in the tree? The server or the content creator? What prevents a server from creating content for anyone? So you can confirm it was not changed, but cannot confirm that the original addition came from the real person? I don't see anything in the docs that talk about cryptographic signatures or key management.
    - goykasi 3y ago
      From what I can tell after digging into the code, the server is responsible for signing everything. I was really hoping that users would have more control in regards to this. I have a similar concern, what prevents the server from publishing without the users consent? Also, I keep seeing discussion about being able to move identities to a new server, but to do that, you need to update your corresponding DID Document -- currently published to https://plc.directory/ https://plc.directory/. Again, that has to be done with the sigining key. What if a server refuses? Is the user stuck and forced to recreate the account/history somewhere else?
      - afiori 3y ago
        > I have a similar concern, what prevents the server from publishing without the users consent? I suspect that the solution would be to run on a trusted server, maybe your own.

brundolf 3y ago

Thanks for weighing in It's disappointing to hear that follower-only/circles (whitelisted viewers) posts are basically incompatible with the current protocol. I'd hoped something could be done where the post content was encrypted in such a way that only specific authenticated users could decrypt it, or something along those lines

capableweb 3y ago
It doesn't sound too hard to layer on top of AT Proto. You already have cryptographic building blocks so you can encrypt content for specific users, I'd guess the only thing that is missing having something like that is the actual UI. But I haven't done a deep-dive into the protocol, just a surface glance so far.
afiori 3y ago
From what I gather it looks like this feature would not be a good fit for the current architecture.

areoform 3y ago

As a team member, one request that I do have is that don't make Clubhouse's mistake. Someone once told me that Clubhouse was like a house party, where your behavior reflected on who invited you. So it kept the initial community quality high. The minute Clubhouse removed that invite-only policy, the community died very quickly and everything was replaced by the worst sludge imaginable. I think you should keep the invite structure, and increase the number of invites to positive users/communities (as you already do!). And use the graph that naturally forms to inform content moderation. Social shame is a strong motivator that hasn't been properly deployed by a platform yet (mobs on twitter don't count). What I'm thinking about is that if someone you invited directly does something horrible like, posts slurs to a user, then the inviter should also get a notice that their invitee was a horrible human being. And if this inviter's invites end up being toxic people, then it may be a good idea to prune that branch of the tree. This structure will limit growth, necessarily, but it will also give you time to solidify a new kind of structure and a new kind of experiment in social media. I think it is possible to have a high-quality social network that scales. Also, please for the love of god, I want to get my mom to use the platform, can you make sure that stuff doesn't break containment?

thealchemistdev 3y ago
Social solutions to social problems. Perfect!
- marvin 3y ago
  Not perfect. Brings the problems of social solutions too. Popularity contests, smooching, people & groups ostracized for status game reasons, other forms of social bullying and so on. It’s maybe great for a frat, but it will struggle for exploring the fallow lands close to controversial topics. This happens to be where a lot of the really important stuff happens, the explorations that lead to growth. You can’t solve this by simple weighting. Most novel true and important things are only realized by a tiny minoroty. And if they happen to be unpopular, forget about it. If the purpose of your social network is to be actually useful for the world, this is an extremely important feature

verdverm 3y ago

How do you intend to prevent someone from manipulating their mirror? Are users signing their messages before publishing to a data server? It is unclear from the documentation.

bnewbold 3y ago
all public account content is in a "repo", commits to the repo are signed, and the identity resolution mechanism gives anybody the current/active signing key. the most direct analogy is to signed git commits. this is an intentional design decision compared to signing individual messages/posts/etc. A "proof" for a single record in the repo is the commit, the record, and the chain of merkle tree nodes connecting the two.
- verdverm 3y ago
  Who signs new nodes in the tree? The server or the content creator? What prevents a server from creating content for anyone? So you can confirm it was not changed, but cannot confirm that the original addition came from the real person? I don't see anything in the docs that talk about cryptographic signatures or key management.
  - goykasi 3y ago
    From what I can tell after digging into the code, the server is responsible for signing everything. I was really hoping that users would have more control in regards to this. I have a similar concern, what prevents the server from publishing without the users consent? Also, I keep seeing discussion about being able to move identities to a new server, but to do that, you need to update your corresponding DID Document -- currently published to https://plc.directory/ https://plc.directory/. Again, that has to be done with the sigining key. What if a server refuses? Is the user stuck and forced to recreate the account/history somewhere else?
    - afiori 3y ago
      > I have a similar concern, what prevents the server from publishing without the users consent? I suspect that the solution would be to run on a trusted server, maybe your own.