Samuel
am very excited about Doll’s appview project. making relays non-archival was the key to making them affordable/easy to scale. Bluesky (the company)’s Bluesky obviously is archival, but for a community to run one cheaply this seems like a great way to keep costs manageable
Doll@dollspace.gay· 4 Oct 2025
The next feature is a configurable retention system. No more balooning database if you dont want it. You will be able to set the days it retains information and anything after that is pruned. You will of course be able to set it to retain all and backfill.
3 16 138
Samuel
@samuel.fm
People have talked about narrow sliced networks to keep costs low - basically make the same compromises as Mastodon. It’s actually way more interesting (imo) to instead compromise on history - you’re reading fresh posts 99.9% of the time after all, and it wouldn’t break feeds like narrow appviews do
4 11 79
Samuel
narrow vs shallow 🤔 a smart client could probably be clever and start hitting the PDS directly when it’s out of the archive window, then use backlinks or something to pull in old replies on demand. inefficient but the main hot path (viewing feeds) is still using the efficient atproto architecture
2 3 47
Samuel
ah yeah of course, when a person logs in you could do a full backfill so they can see their own history! and so you only need to pay the cost of an archival appview for the number of users of your *app* rather than the total users of the full network
1 27
Doll
You can do a full backfill on the whole network or configurable by days, but thats a good idea and doll will add that in too
14
Liz Fong-Jones (方禮真)
An opportunity is tiering: data that is hot for rendering feeds is different than "what did this user say about X over multiple months?" which is a real use case that I have done recently for OSINT and that a shorter term view couldn't do. That being said I could also interrogate their PDS so...
2 6
austin
automatic tiering should be pretty easy since you get to pick your storage layer. what’d be fun is adaptive sampling
4
Liz Fong-Jones (方禮真)
OSINT archival searches do not need to be hosted from the same infrastructure as real-time feeds, can use cheaper object storage, can build indices and bloom filters as they go with pointers to the content rather than the full content etc etc
4
Dark
i do think its worth coming up with methods to limit the size of the ingested network because it reduces the *processing* requirements required to run an appview doesn't need to be done like mastodon because the global firehose gives a lot of flexibility in what accounts you want to actually handle
2 4
Dark
one method i've thought of is coming up with a way to handle all incoming events involving approximately 50k or so accounts and backfilling other things as needed this would be a pain on activitypub but atproto would make it *much* easier to do
3