Comment by bnewbold | Hacker News Reader

Comment by bnewbold | Hacker News Reader

Parent Full thread

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/, working with the full social graph, pulled via public API

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?

> where your behavior reflected on who invited you

Ages ago, I suggested that slashdot (or successor) adopt a mafia-style system of vouching. So that members police their own.

I invite you to slashdot, so your reputation (karma, whatever) impacts my own. In a way, you become my responsibility. To protect my own rep, I may have to kick you off the system.

If you in turn invite others, they also factor into my rep. Kicking you off would also kick off all your invites. And so on.

Social solutions to social problems. Perfect!

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

Perfect wasn't the right word to use, but in the age of LLMs, deep fake images, video, and voice; No one should take to heart anything they see on these screens.

Don't take this the wrong way, I have no reason to believe that you're a real person and not a fun contrarian bot. And you to myself as well. :)

In either case, our wetware isn't suited for social interactions at this scale. I think small, invite only, social rings are much better than what we have now. Yeah, people are going to play silly games, but we won't see a solution to that for a very long time.

As for the people who are eager to explore the edges of controversial ideas; they should be aware of how to discern a group that values progression through challenge over one that demands consensus, and steer clear of the latter.

And to your final point about being useful to the world, it would be better to strive to build a system useful to just your loved ones and local community. Plenty of people exhaust themselves over words on a screen from fake people on the other side of the planet. We have enough ancient and contemporary text from philosophers and religious leaders to remind us that people, specifically the people physically around us, matter more than anything. But of course, there's no money to be made with IT cookbooks, so we don't talk about them.

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

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.

From what I gather it looks like this feature would not be a good fit for the current architecture.

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.

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.

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.

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/. 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?

There are two keys that can be used for DID updates. One is the signing key that the publishing server may also control, one one is the recovery key. If a content server goes rogue, the recovery key can be used within 72 hours to retroactive undo changes made to the DID (if the server did that).

If the server just maliciously messed with your data repository, you just use the recovery key. If the malicious content server did not try to rotate the recovery key, you can just use it to reset the signing key, regardless of if the content server rotated it. If it did malicious try to rotate the recovery key, as long as you notice within 72 hours, you can fork a new DID history from some state that was current within the last 72 hours that has your old recovery key.

Either way, you use the recovery key to rotate the signing key, to something you control. Now, you can repoint your DID to a new content server, upload your unadulterated post history to it.

Also, the core of the protocol does not strictly require that the content server have your publishing keys. In theory a client can create new posts, sign them and upload them. This will mean that certain API methods that exist that do things like add a new post won't work, which is theoretically fine if you only ever want to post from fully trusted clients that could be given access to your signing key, create a new commit, and upload it.

Also it is not yet clear if all servers will allow such usage. In theory a content server could refuse to host the data repositories for users if it lacks the signing key for the user.

Footnote: These content servers are formally called Personal Data Servers. I used content servers throughout this post to be clear that I am not talking about plc.directory or other such ancillary servers.

> 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.

most people won't want to manage their keys, the UX around that sucks, so federation only in name?

"most people don't manage their keys and use semi-trusted intermediaries of their choice" sound like a central example of federation.

"Everybody is their own server" is decentralization

Reply on news.ycombinator.com