Futur announced shutting down Zeppelin Social, which was a fork of bsky social app with all the data for bsky posts.
Quoting a few posts from the thread
now for a bit more detail: the goal with zeppelin was to prove that it was possible. since claims about how hard it is were everywhere, & while the pieces were all there, no one was actually doing it, so I did
to me the notion of an alternative appview has always been a bit silly. the authoritative data is on the PDS, the bluesky appview serves a particular aggregated view of it, zeppelin serves.. the same data but somewhat less accurate?
broadly I think the value in atproto is in being able to build stuff like flashes.blue atop others’ data, or trivially build new applications entirely
but running an identical copy of someone else’s application? I certainly think it’s useful that we can do this, but that utility will primarily occur in the form of being able to keep going if/when bluesky stops existing, not in the mere existence of a copy when a more accurate one already exists at api.bsky.app
He goes on to point to constellation work “big app aggregation without big app hardware” as being interesting.
Code and infrastructure work remains in the GitHub repo zeppelin-social · GitHub
Aside from Constellation https://www.microcosm.blue/, the new Slices https://slices.network/ is also relevant.
My mental model for this is also that other data types — like Smoke Signal events — can take different approaches: focusing on a data lake of events while allowing for multiple products on top.
1 Like
Yeah it’s super interesting to see Futur’s posts about their plans for Zeppelin.
I’m a little disappointed to see that their interest in running a Bluesky AppServer was solely focused on the technical aspects. On the one hand it’s great to have confirmation that we can run alternate AppServers, and that it is within reach for a modest budget and technical knowhow.
On the other hand, like the power and the promise of running in ATProto is that it’s open enough to defy centralization, and that users don’t have to be locked into a single set of service providers.
I also don’t agree with Futur’s contention that just because data is available in PDSes that having alternate AppServers don’t matter. I feel like that’s equivalent to saying that because books exist, we don’t need libraries or indexes.
Apps and AppServers are the gateway and front door for accessing the network and owns the experiential interface for most users. In that way Apps and AppServers feel like the most critical part of the network in many ways.
The more complicated argument i can see from Futur’s end is, if the Bluesky PBC AppServer is already good enough, why bother paying server bills to run something that has no technical feature differentiation? And for that, my response is, there are allllllll kinds of reasons why a community’s priorities or operations might differ from Bluesky the PBC, and they might want to take on the operational burden of controlling an AppServer. Then we land in the territory of the ROI to the community shoulder the costs of running the AppServer, vs just living w/ Bluesky PBC’s operations of their servers.
I think it’s useful to write up what might want to be done differently by a community and at what level one has to run something.
Verification and default feeds are two that make a lot of sense to me as things to override. And that can be done “just” as a client, I think?
What can only be done at the appview level? Do we have a list of these items?
I have failed to build community / get buy in many times! It’s hard work, and you have to actually have some shared interest, plus a product vision of what meets that community. Some times you have to show not tell first and then it takes longer than you expect. This may be obvious but I also wanted to say it out loud.
For me, this hits different. Does there need to be a second Bluesky microblog clone? Who runs it and what is their theory of that product?
I have couple of ideas, including language specific ones.
Does there need to be a second Bluesky microblog clone? Who runs it and what is their theory of that product?
Yeah! I think this is one of the most interesting questions. Are there feature spaces where two or more products can co-exist.
One of the possible futures is that ATProto apps “own” a set of lexicons (and the NSID thing kind of frames the way for that), and users know where to go for the canonical experience for lexical records of any particular type.
There’s another possible future where there are operational, governance or feature differentiation of AppServers (which starts to sound a little bit like the Fediverse).