3 ms·

I believe there’s currently a single relay. When there are multiple relays, each will have a different view of the network, and the one that includes more posts

I believe there’s currently a single relay. When there are multiple relays, each will have a different view of the network, and the one that includes more posts will be better than the others. It might be quite hard to get relay diversity rather than using a single dominant relay, sort of like attempting to get traction for an alternative DNS system. Then, if your posts don’t get picked up by the dominant relay then it seems like you’re out of luck? But it’s still very early, so perhaps it won’t work out that way. And even if there is a dominant relay, well, GitHub isn’t so bad, and there are alternatives.

wmf 3y ago
I would expect every relay to have everything (modulo different opinions about illegal content). Why do you think they would have different views of the network?
- s1gnp0st 3y ago
  It's virtually guaranteed that different relays will take different views regarding disinformation, harm, etc. This is probably good, too. I personally don't want my hand held, but recognize that others justifiably want someone else to filter out gore, or even opinions they find sufficiently off-putting. I don't want to ram particular content down anyone else's throat, but I'm 100% opposed to anyone making that decision for me.
  - wmf 3y ago
    My understanding is that relays will not filter anything except really illegal material (child porn). Moderation is based on labeling, not deleting.
    - layer8 3y ago
      Is it possible for a relay to filter individual posts, or do the Merkle trees prevent that? (They would if they need to be signed by the originating user.)
    - gpm 3y ago
      Unless they want to provide free file storage to the world... surely they must delete spam.
    - PathfinderBot 3y ago
      I'm part of a marginalised group that is often considered to be illegal in many countries, or at the very least, very off-putting. (In 50 years, perhaps, things will change and we will be more accepted. To be specific, it's a grey area in the U.S.) I'm interested in BlueSky but the relays are a worrying "point of failure" if they can just block me from there. I'll be more interested if there are multiple relays that I can use in parallel, with at least one being friendly to us, so I can still participate. Currently on the Fediverse it mostly works since we can connect directly to other servers, and there's no SPOF. But I would love to use BlueSky due to the better protocol design! Just more relays would be good. ... Wait, can we self host relays? And is it plausible for a community to do that? I couldn't find anything about it.
      - wmf 3y ago
        You can host your own relay but if you want accurate likes/replies/etc you need to crawl the entire Bluesky which could be quite expensive in the future.
- skybrian 3y ago
  Well, they'll try. The relay plays a similar role to a search engine, though without the ranking. Why do different search engines have different content? As others have said, spam and illegal content are the most likely reasons. We might also compare to email delivery; maybe ideally every message would be delivered, but in the real world, they aren't, and open relays are a hazard.
layer8 3y ago
I would expect clients (App Views) to be able to use multiple relays in parallel if needed. That would be like having a local GitHub UI pulling data from several GitHub instances (“relays”) that may host different but potentially overlapping sets of repositories. This would be like a Usenet client aggregating newsgroups from several NNTP servers.
- e12e 3y ago
  More like a local git repo having multiple remotes?
  - arcalinea 3y ago
    Yes — the canonical source of truth for a user's data is their "data repository" which is analogous to a git repo. These can really be passed around any way you want. Our current relay architecture was designed to support large, real-time scale, but other configurations are possible as well, since all the pieces here are composable.
evbogue 3y ago
I have previously found Bluesky kind of confusing, but I've recently realized that it was mostly the terminology that was confusing me. Imagine if you instead referred to the the system as [microblogs] -> [indexer] -> [client] There's a lot more to it, but I think this is the basics of how Bluesky works. They just call everything something different than you might think it should be called. The indexer is only necessary because the user ids do not remain static on the system. Instead there is some weird cryptographic reshuffling going on where DID:PLC starts as a substring of a hash and then because of 'key rotation' the user id of every user actually changes out from under the user themselves over time. Imagine a system such as Livejournal but your handle is constantly changing so you need an authority to keep track of the handle changing. And of course you are only allowed to post short messages with no titles or markdown support. I'm personally waiting for a new DID:PLC where you can get a static pubkey where you sign the messages with a private key because I think that'll be way less stuff to keep track of and it'll make self-hosting and local-first development much easier.
- steveklabnik 3y ago
  Yeah, I hear you about the names. When talking about this on bluesky, someone came up with "data store -> indexer -> view", which I think fits a bit nicer too. https://bsky.app/profile/aparker.io/post/3km6zvwfen727 https://bsky.app/profile/aparker.io/post/3km6zvwfen727
  - evbogue 3y ago
    "data store -> indexer -> view" works very well too. I hadn't seen this post, I guess we were thinking simultaneously.
- str4d 3y ago
  > The indexer is only necessary because the user ids do not remain static on the system. Instead there is some weird cryptographic reshuffling going on where DID:PLC starts as a substring of a hash and then because of 'key rotation' the user id of every user actually changes out from under the user themselves over time. The user IDs (e.g. did:plc or did:web) do not change over time. You are correct that a user that uses did:plc has that generated from a hash (of their initial repository state), but subsequent additions to or deletions from the repo don't change the DID. Likewise, if you set up your repository with did:web, the domain you pick is fixed, and you lose access to your repo if you lose control of that domain. What is changing with key rotation is the repo signing keys that authorize updates to the user repo. If you run an entirely self-hosted PDS then you can choose to never rotate that key, and then you have a "static private key" repository. But key rotation is a necessary part of the design, in part to enable account migration (you wouldn't want an old PDS to still be allowed to make changes to your repository, so you'd rotate those keys to remove the old server's key and add the new server's key).

wmf 3y ago

I would expect every relay to have everything (modulo different opinions about illegal content). Why do you think they would have different views of the network?

s1gnp0st 3y ago
It's virtually guaranteed that different relays will take different views regarding disinformation, harm, etc. This is probably good, too. I personally don't want my hand held, but recognize that others justifiably want someone else to filter out gore, or even opinions they find sufficiently off-putting. I don't want to ram particular content down anyone else's throat, but I'm 100% opposed to anyone making that decision for me.
- wmf 3y ago
  My understanding is that relays will not filter anything except really illegal material (child porn). Moderation is based on labeling, not deleting.
  - layer8 3y ago
    Is it possible for a relay to filter individual posts, or do the Merkle trees prevent that? (They would if they need to be signed by the originating user.)
  - gpm 3y ago
    Unless they want to provide free file storage to the world... surely they must delete spam.
  - PathfinderBot 3y ago
    I'm part of a marginalised group that is often considered to be illegal in many countries, or at the very least, very off-putting. (In 50 years, perhaps, things will change and we will be more accepted. To be specific, it's a grey area in the U.S.) I'm interested in BlueSky but the relays are a worrying "point of failure" if they can just block me from there. I'll be more interested if there are multiple relays that I can use in parallel, with at least one being friendly to us, so I can still participate. Currently on the Fediverse it mostly works since we can connect directly to other servers, and there's no SPOF. But I would love to use BlueSky due to the better protocol design! Just more relays would be good. ... Wait, can we self host relays? And is it plausible for a community to do that? I couldn't find anything about it.
    - wmf 3y ago
      You can host your own relay but if you want accurate likes/replies/etc you need to crawl the entire Bluesky which could be quite expensive in the future.
skybrian 3y ago
Well, they'll try. The relay plays a similar role to a search engine, though without the ranking. Why do different search engines have different content? As others have said, spam and illegal content are the most likely reasons. We might also compare to email delivery; maybe ideally every message would be delivered, but in the real world, they aren't, and open relays are a hazard.

layer8 3y ago

I would expect clients (App Views) to be able to use multiple relays in parallel if needed. That would be like having a local GitHub UI pulling data from several GitHub instances (“relays”) that may host different but potentially overlapping sets of repositories. This would be like a Usenet client aggregating newsgroups from several NNTP servers.

e12e 3y ago
More like a local git repo having multiple remotes?
- arcalinea 3y ago
  Yes — the canonical source of truth for a user's data is their "data repository" which is analogous to a git repo. These can really be passed around any way you want. Our current relay architecture was designed to support large, real-time scale, but other configurations are possible as well, since all the pieces here are composable.

evbogue 3y ago

I have previously found Bluesky kind of confusing, but I've recently realized that it was mostly the terminology that was confusing me. Imagine if you instead referred to the the system as [microblogs] -> [indexer] -> [client] There's a lot more to it, but I think this is the basics of how Bluesky works. They just call everything something different than you might think it should be called. The indexer is only necessary because the user ids do not remain static on the system. Instead there is some weird cryptographic reshuffling going on where DID:PLC starts as a substring of a hash and then because of 'key rotation' the user id of every user actually changes out from under the user themselves over time. Imagine a system such as Livejournal but your handle is constantly changing so you need an authority to keep track of the handle changing. And of course you are only allowed to post short messages with no titles or markdown support. I'm personally waiting for a new DID:PLC where you can get a static pubkey where you sign the messages with a private key because I think that'll be way less stuff to keep track of and it'll make self-hosting and local-first development much easier.

steveklabnik 3y ago
Yeah, I hear you about the names. When talking about this on bluesky, someone came up with "data store -> indexer -> view", which I think fits a bit nicer too. https://bsky.app/profile/aparker.io/post/3km6zvwfen727 https://bsky.app/profile/aparker.io/post/3km6zvwfen727
- evbogue 3y ago
  "data store -> indexer -> view" works very well too. I hadn't seen this post, I guess we were thinking simultaneously.
str4d 3y ago
> The indexer is only necessary because the user ids do not remain static on the system. Instead there is some weird cryptographic reshuffling going on where DID:PLC starts as a substring of a hash and then because of 'key rotation' the user id of every user actually changes out from under the user themselves over time. The user IDs (e.g. did:plc or did:web) do not change over time. You are correct that a user that uses did:plc has that generated from a hash (of their initial repository state), but subsequent additions to or deletions from the repo don't change the DID. Likewise, if you set up your repository with did:web, the domain you pick is fixed, and you lose access to your repo if you lose control of that domain. What is changing with key rotation is the repo signing keys that authorize updates to the user repo. If you run an entirely self-hosted PDS then you can choose to never rotate that key, and then you have a "static private key" repository. But key rotation is a necessary part of the design, in part to enable account migration (you wouldn't want an old PDS to still be allowed to make changes to your repository, so you'd rotate those keys to remove the old server's key and add the new server's key).