Hacker News Reader

Comment by nightpool | Hacker News Reader

Except for the fact that it requires a centralized directory server that you can be banned from at any time, with no recourse. And for users, being independent from Bluesky requires owning a DNS name and paying for it yearly—a big step backwards from Mastodon where a group of users can come together and live on a server run by an admin they trust without needing their own DNS names. It replaces social trust that's more accessible for a lot of non-technical users with a more complicated kind of technical trust that requires a high level of technical sophistication (Can you imagine hundreds of thousands of twitter users all signing up for a registrar and buying their own domain names?)

View on HN

You've identified a real problem but blamed the wrong target. We don't need to avoid using domain names, we need to make them an order of magnitude easier for laypeople to buy and use.

99% of people who could benefit from owning a domain should never have to know what a DNS record or TLS cert is. This should all be managed by apps through a simple delegation system built on OAuth2.

You log on to bsky.app, they say, "want to connect a domain?". You say yes and get redirected to your domain registrar, where you grant access to for bsky.app to have control over bsky.example.com until you revoke access.

DomainConnect[0] should solve this but in practice it's turned out to be very gatekeepy in my opinion.

[0]: https://www.domainconnect.org/

This is an interesting take! I don't necessarily disagree with it—we could definitely make the DNS system more accessible than it is today—but I don't think it's the panacea either, there are still a lot of costs and paperwork involved with owning a domain name that aren't related to the actual technical knowledge required. How is my 12 year old cousin whose parents don't understand technology supposed to buy a domain name just to be able to comment on a youtube video?

Certainly I think there are regulatory and social issues as well. The current system was built in a time where it made far less sense for that 12 yo to have their own domain name. But they also didn't have their own phone numbers back then, but the phone system evolved so they could. DNS needs to evolve too.

You're only addressing half the issue here. By delegating control of your domain to bsky.app, you're still beholden to a centralized ban list and retain no control over your own instance.

If they ban you then you take everything, including your profile domain, and move somewhere else. This mobility would do a lot to ensure they don't ban users without a good reason. It's incentive alignment and insurance.

Are you saying that if you get banned you have the ability to take your bluesky name and all data to another server somewhere?

I have not ready anything about the protocol yet, is there something in it that keeps all your data accessible to you after a ban?

Is list of contacts, other people's posts and such part of that move or what exactly is left to someone after they are banned?

Edit: oh wait I'm completely wrong, that's not a key, that's an ID in a directory, lol. The public key thing is just a plan.

There's a thing called DID that identifies you. There's a few options, but one is called "DID PLC" with a sample implementation here:

https://github.com/did-method-plc/did-method-plc

With the disclaimer that I haven't dug into it seriously enough, I understand it's a public key (that I can also rotate) that I can use to prove that an account somewhere else is really mine. Note that I have no idea what the private key is, or how to dig it out - I'm sure that's documented somewhere, but I wasn't interested enough for now.

TL;DR: there definitely is a theoretical mechanism for users to "take their toys with them." How it works out in practice is a different matter. I suspect most users wouldn't know they're supposed to keep a bundle of data stored somewhere for a dark hour. I also wonder how the protocol protects itself from people accidentally putting that data in public.

There are no safe haven registrar that are immune from harassment against lawful contents. There's no guarantee that you can port-out domains against registrar's will, even if it's technically your property.

The whole "we can just use DNS names as ID and it'll be unbannable" idea is just relying on the fact that domain names aren't normally used as social media IDs and that more neutrality is expected from registrars, and neither of these presumptions are guaranteed.

Once enough users start using domain names and gets >100k daily likes with anime illustrations, same people as who were problems ARE going to get mad and set up their systems to just hammer Namecheap, GoDaddy, Gandi, Porkbun, until their support gives in just like it always happened. If they didn't, they inject faults in credit card payments, make their authoritative servers unresolvable in UK, Apple devices, on 1.1.1.1 and 8.8.8.8, so on and forth, until they do.

What are you optimizing for and what's your threat model? Personally I'm optimizing for UX and data ownership. One reason centralized services are bad is they tend to turn into monopolies. Once there's no competition there's no incentive for UX to be good. More ads, less useful features, more useless features, etc.

Using a decentralized protocol and providing custom domains is sufficient for me.

If you're optimizing for censorship resistance and your threat model is that registrars want to take you down because there are enough people mad about what you're posting, you're going to have to make UX tradeoffs that most people don't and shouldn't need to.

From GP:

> If they ban you then you take everything, including your profile domain, ...

This reads like censorship resistance against moderation/management going insane on its own, to me. And in reality, that rarely happens. It's ongoing on Twitter, kind of, but that's less than once in a decade occurrence, and the crazy element wasn't internal.

What happens more often is some fundamentalist group or something starts harassing companies, often leveraging advertisers, credit card companies, perhaps some backend APIs too, sometimes even foreign laws way outside jurisdictions, to get them swallow their agendas. That leads to bans and insane policies getting introduced.

And, if you look at what happened to Twitter in last few years, I think you can see the latter of above two descriptions is closer to what happened to it; whether it was foreign conspiracy, or purely to that guy's insanity, or politics, it was external force that lead to the situation that necessitated escape. It was sane-ish up to the acquisition.

The other issue is that I fundamentally don't think the problems of moderation and hosting are "separable" as the paper claims—the moderation of your content is intrinsic to the question of "who wants to be responsible for hosting and paying for this content?". And people are going to want to use moderation systems that make moderation decisions they agree with and support—they're not going to want to be paying for a hosting provider that hosts content they disagree with. That's why I see the fediverse "plurality of networks" federated model winning out in the end, because it can be funded and operated by small groups of people interoperating with each other rather then requiring large centralized directory resources that nobody wants to pay for.

Moderation is only an issue at "commercial" scale. Any small community can easily solve moderation. One critique I have about most modern business plans is that they are looking for large scale and little responsibility.

Nightpool has been an admin of AcitvityPub servers of all sizes for years now and is versed in the moderation challenges therein, I'm not sure they'd agree :) I'm not sure I agree that it's a solvable issue at community scale.

Yeah, I don't think moderation is "solved" at all on the community scale, but my point is that ActivityPub servers are just way more likely to be at that "community" scale, and Bluesky—as a more flat protocol with a lot of discovery and indexing features—is not. So I think they have a lot better chance of having communities that can reach a local moderation equilibrium.

I guess I'm looking at it from the Lens of the community. If a community can't solve its moderation issue through social standards the community degrades.

Once the community degrades to having no social standards there is no point in moderation.

I helped run a moderate a small forum community in the early aughts. We only had maybe 800-1000 active users at our peak. Moderation was fucking terrible, and not 'solved'. We had several users we elevated into moderator positions and still.. I think we were running about 1.5 moderators per 100 active users on average.

800 to a thousand sounds like a lot to me. The early aughts were also different times.

I think this comment is kind of correct, the moderation problem can be overlooked until the system scales(IMO not until individual participating instances scale but until the whole system becomes relevant), and thereafter we'd come back to the problem of bad actors and external pressures.

I thought it was cheaper not to look at the content, than to look at it. That just leaves legal responsibility as an issue.

That requires each and every user to do the moderation for themselves. Which few if any want. Most users actually want moderation, as long as they can decide whose ban list applies to the content they see.

> And for users, being independent from Bluesky requires owning a DNS name and paying for it yearly

This is not really true. DNS allows you to set your name to a domain, but ultimately all of your posts are tied to your DID. If you wanted to move from steveklabnik.bsky.app to steveklabnik.whatever.app, you could do that still, no DNS required. You won't lose anything. The DNS stuff is effectively vanity.

At present all the DIDs issued through bluesky use plc for resolution, which is a centralised directory managed by bluesky

Yes, I agree this is a weak point. It's also one that the team is aware of and seemingly has the right amount of discomfort with. I see temporary compromises like this as an example of the pragmatic decision making needed to ship, and trust that they will do the right things here, but I also understand some skepticism.

It's not a 'weak point' it's a fatal flaw.

Given that it is a non-essential part of how the protocol works, I disagree, but I understand that reasonable people may differ.

PLC uses signed logs similar to certificate transparency. We have a lot of options for where to take it. There may be a distributed/decentralized hosting system if we can settle on a consensus model we're comfortable with. Otherwise it will be some kind of org management model.

The other direction we've got is did:web, which is already used in some cases, and has some tradeoffs but is a strong option.

For now. As I understand it (from talking to them in person a few years ago), they don't want it to stay like that forever. They want to eventually invite more organisations to run name resolution servers, and they have some clever ideas about how to keep all those servers & organisations honest.

My understanding is that this only works if you're using their centralized PLC DID, which I think only works if you sign up through their website? Maybe I'm mistaken about that or they removed that restriction, I don't see any mentions of that in the docs today. Users using the `web:` DID need to use the .well-known resolution system predicated on owning a domain name and their identity is tied to that domain name.

In general, I guess I'm just pessimistic of the ability for any DID system to exist that isn't either centralized or majorly user-unfriendly. I think that reasoning on a "local scope" like ActivityPub does and worrying less about global identity is just a better long-term solution for users and works better with how people are practically using social media today (think about the proliferation of a million discord servers each with effectively their own user identity....)

Yeah, as you can see from the sub-thread, I maybe over-stepped a small amount here. I am thinking about what is required by the protocol, and that is just 'any DID.' You are right to point out that web: and plc: both have certain practical drawbacks today. I am confident that because this problem is considered carefully by the team, that this will be 100% true in the future, but you're also right that there are real restrictions today. I will be sure to be more careful in the future.

> In general, I guess I'm just pessimistic of the ability for any DID system to exist that isn't either centralized or majorly user-unfriendly.

That's fair. Time will tell :)

Well, or a group of users can come together and attach their identity to a DNS server run by an admin they trust. If I register pinksky.com, it is fairly cheap for me to hand out subdomains to Bluesky users -- certainly easier than running a Mastodon instance.

I think the questions about indexers and firehose servers are more relevant to the question of centralizations. Identity is much easier to solve.

> being independent from Bluesky requires owning a DNS name and paying for it yearly—a big step backwards from Mastodon where a group of users can come together and live on a server run by an admin they trust

In the DNS, that’s called a subdomain. I.e. a group of users can come together and buy a domain name and all use different subdomains, completely without any additional cost per user.

> and for users, being independent from Bluesky requires owning a DNS name and paying for it yearly

I don't think so. Anyone can set up a server with a DNS entry and then hand out subdomains to users. It's only sekf-hosted folk who need to pay for a domain name

actually you can use any kind of identity system that uses a did. it’s not dependent on dns alone.

(we run the largest instance of atproto outside of bluesky)

My understanding is that bluesky will only support interoperating with their own centralized PLC system (which other developers currently can't access) or the did:web: protocol. Is that not true?

It doesn't work with subdomains?

Users. Don't. Care.

Reply on news.ycombinator.com