at://bnewbold.net/sh.tangled.feed.comment/3mybfw5lssu22
Back to Collection
Record JSON
{
"$type": "sh.tangled.feed.comment",
"body": {
"$type": "sh.tangled.markup.markdown",
"original": "We considered an architecture like this for the atproto space protocol itself, but did not do it because space data does not have redistributable authenticity (aka, doesn't have direct cryptographic signatures), and thus you can't trust the authenticity of data received from the space host (eg, group host).\n\nIn other words, the group host is at best jetstream, not the authenticated firehose. And unlike with jetstream, the group host is often \"just some random untrusted server\", not a single host that you as a developer have chosen to trust.\n\nWe (Bluesky protocol/atmosphere team) expect to implement and maintain something like tap/jetstream that app devs can run on their own to help offload a lot of the space sync logic. That will work across many spaces and group hosts.\n\nIt is interesting to see hear this kind of proposal, and we can iterate on the proposed protocol in the future if the architecture ends up being too much friction. But I think a change like this would be pretty big this late in the process.\n\nI do think that there might be a place for group hosts or app services to emit trusted event streams in certain circumstances. One example is a group host hooking up to automated moderation services. But I think those are pretty limited.",
"text": "We considered an architecture like this for the atproto space protocol itself, but did not do it because space data does not have redistributable authenticity (aka, doesn't have direct cryptographic signatures), and thus you can't trust the authenticity of data received from the space host (eg, group host).\n\nIn other words, the group host is at best jetstream, not the authenticated firehose. And unlike with jetstream, the group host is often \"just some random untrusted server\", not a single host that you as a developer have chosen to trust.\n\nWe (Bluesky protocol/atmosphere team) expect to implement and maintain something like tap/jetstream that app devs can run on their own to help offload a lot of the space sync logic. That will work across many spaces and group hosts.\n\nIt is interesting to see hear this kind of proposal, and we can iterate on the proposed protocol in the future if the architecture ends up being too much friction. But I think a change like this would be pretty big this late in the process.\n\nI do think that there might be a place for group hosts or app services to emit trusted event streams in certain circumstances. One example is a group host hooking up to automated moderation services. But I think those are pretty limited."
},
"createdAt": "2026-10-20T03:47:05+03:00",
"subject": {
"cid": "bafyreiaw4xocoxgvumcex657efpmyacut54hbvc3crws7fl5jwih32qkzq",
"uri": "at://did:plc:bcgltzqazw5tb6k2g3ttenbj/sh.tangled.repo.issue/3mxruxiy5bf22"
}
}