Infrastructure is just a service provided. Reminds me of a baker in the UK who refused to bake a cake for a gay couple based on their religious beliefs which created a lot of discussion. Should they be compelled to provide their service or have a right to choose?

I think the only way to truly separate infrastructure from ideology is if the infrastructure (i.e. relays) have no view of what they are relaying.

It’s probably not just going to be ideology either. There will be legislative reasons. Again, for the UK I wouldn’t be surprised if some relays services feel compelled to not offer services to UK residents.

And we should make sure there’s more than 1 baker in town :-)

Reply to this note

Please Login to reply.

Discussion

That happened in USA, why do you people always tell stories about your own country but change it to be the UK or somewhere else?

“You Americans” always think it’s about you ;-) Maybe there are more than 1 gay cake?

https://www.bbc.com/news/uk-northern-ireland-32065233

The comparison to a restaurant is not entirely accurate, atproto PDS is more of a general-purpose infrastructure. It's complicated

https://gist.github.com/burningtree/d4aa172470293bdf2939c993cf48bbd4#if-you-dont-like-ideological-pdss-just-use-a-different-one--its-like-complaining-about-vegan-restaurants

The last thing I want to do is order someone what to do with their servers. I'm an anarcho-capitalist (anarcho-convivialist)

Well, I’m glad to see you here anyway :-)

> "I think the only way to truly separate infrastructure from ideology is if the infrastructure (i.e. relays) have no view of what they are relaying."

I completely agree, that *guarantees* neutrality. However, the entire internet and its neutrality today are not based on guarantees, but on culture. I expected AT Protocol to understand this, but they have turned it 180° and are making this cultural neutrality a threat.

Thank you for the welcome :) I hope you'll forgive me for my shitposting about bitcoin sometimes ;)

Their position, broken down into consequences, is that culturally neutral infrastructure is the wrong approach. That we inherently support racists when we have neutral web hosts or email providers, that the right approach is ideology-based because it prioritizes "community safety".

It seems a bit like the Core vs Knots case to me. One side wants to have nodes as neutral as possible and the other side want to bring unnecessary ideological baggage into it.

"Their position, broken down into consequences, is that culturally neutral infrastructure is the wrong approach."

To be clear, if you agree, this is more the position of the "masses" on Bluesky, rather than the people at the top (Jay Graber etc), who seem to be at least on paper free-speech maxis?

Yes I agree, It's the view of the masses, but also the majority opinion of the developers that make up the ecosystem (from my pov).

I believe that Jay and the Bluesky team mean it honestly, but it's impossible for them to resist the community pressure and this "enshittification".

Cory Doctorow diagnosed this a long time ago: https://doctorow.medium.com/https-pluralistic-net-2024-11-02-ulysses-pact-tie-yourself-to-a-federated-mast-b2f89bb5b4d8

I mean, Cory takes it more from the point of view of a self-devouring institution and external players like VCs, but I think it nicely illustrates the pressure the current Bluesky team is under from all sides.

Jay and Bluesky's team has fallen into a trap from which there is no escape. They need funding from VCs and they won't get it if they go against the community, because that would mean less growth. I wouldn't want to be in their place.

Was this not the observation Dorsey made that brought him to remove his bluesky account?

Yeah, Dorsey was right. However, I'm glad I learned this the hard way. Trusting famous people with tens of thousands of followers is always a gamble.

albeit that things can be reasoned through in advance, or reasoning by others can be assessed, instead of just ''trusting''; fair enough, such hard ways make for the best foundations anyway :)

A big part of these types of outcomes is also based on the community that forms around them. Bluesky ended up, for various reasons largely unrelated to its underlying protocol, being adopted by a very specific community, and that community views policing untoward speech as a core part of how social media should operate (not passing judgement on that here!). While the protocol design attempted to do that at a higher layer, the community’s strong stance on moderation and the developer’s need to fight urgent spam and moderation fires meant that protocol neutrality took a back seat. Once it was there, with a rapidly-growing community that viewed this as good, it wasn’t coming back.

Sure, but to borrow some ideas from #urbanism, I do think that "infrastructure determines culture" to a certain extent here.... The major barriers of entry for anyone like Blacksky to spin up alternative systems creates a situation where the "exit / voice" dynamic is heavily skewed towards "voice", and users feel their only option is to fight battles rather than do their own thing.

The design of Bluesky was intended to allow for tribal portability such that a PSS banning you didn’t really matter, you’d just move your data and use a new one. AFAIU (and I don’t follow it closely really) that isn’t quite what has happened.

Errr trivial portability lol

Trivial portability is great and solves one important issue, but in the context of today's society and the weaponization of identity, it also accelerates other problems, perhaps much more serious ones.

"I hope you'll forgive me for my shitposting about bitcoin sometimes ;)"

dude, that's like 99% of nostr anyway

"I think the only way to truly separate infrastructure from ideology is if the infrastructure (i.e. relays) have no view of what they are relaying."

I agree, but one could make the argument that as Nostr scales, this would be untenable because relays would be crushed by spam.

But there are ways around that, I.e. Web of Trust and/or Proof of Work, that would obviate the necessity of analyzing the content of a message (and therefore being responsible for its transmission if it's "bad"), while still serving as an inhibitor of spam.

In "high spam traffic", proof of work could even be set at (say) 1 second, which would be no problem for most users.

That’s where hashcash came from I believe and same principles here could be used here (using Bitcoin for relays rather than email) that it becomes uneconomical to post excessive spam. FYI nostr:nprofile1qqsqyredyxhqn0e4ln0mvh0v79rchpr0taeg4vcvt64te4kssx5pc0spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3camnwvaz7tmwdaehgu3dwfjkccte9emkcann9eehqctrv52em09e

That works for encrypted DM type notes. Not sure about public stuff though if the relay remained in the dark about what it’s transmitting unless the message is sharded and that sounds complicated.

Well you're not using "Bitcoin" per se, it's just adding proof of work to messages. Coracle does this. It just uses your computer to do proof of work on a hash of your message.

No reason why it couldn't work for public notes too. Nothing is encrypted.

It's the same kind of thing that Anubis does: Force the user instead of some "captcha" to do a small amount of computational work, that's no problem if it's a human but becomes uneconomical if it's a massive web scraper" https://anubis.techaro.lol/

The only real way to make the relay not know what it's sending but not have everything encrypted is to make the operator unable to communicate preferences to the relay, which means relays in enclaves with attested runtime code meeting protocol spec, and if no proof-of-blind-enclave then not considered protocol compliant.

Yeah, I mean... I wasn't thinking of the relay operator "provably" not knowing what's getting relayed, but rather just the idea of the operator having a general policy of "not caring."

The enclave approach would be close to that, the operator could obviously know what's on the relay, because anyone can query the relay, and the notes are not encrypted. But the op wouldn't be able to do anything with this knowledge, because to change the code of the relay would require breaking the attestation and being booted from protocol compliance. So code-enforced not caring, in a way.

Interesting!