In light of Zeppelin.Social ceasing development and dev activity on Deer.Social slowing down, I wanted to gauge the IndieSky community’s interest in the continued legacy and usefulness of these types of appview projects.
Northsky Social’s plan for Phase 2 of our development (after Phase 1: PDS Migration), is to set up a fully functional appview stack and begin expanding it in a variety of ways, including:
In-app Moderation Capabilities
Interface customization
and more!
Since we’re committed to expanding off of the social-app project, we were wondering if there’s interest in an intermediary, maintained, testbed/sandbox appview that we maintain to help others in the ecosystem who are wanting to test features, lexicons, etc…
Bluesky Appview → Intermediary Social Appview (we maintain) → Our fork / Your fork
We figure since we’ll be needing to keep our version up to date with Bluesky (with some notable exceptions) that it might be helpful to the overall developer community for us to take this on. It might be something we seek additional funding for too.
What do you think? Would this be helpful? Sound off below!
IMO this would have been amazing when I’d started on Bluemoji. I spent several evenings trying to fork social-app in a way that preserved the existing code base such that it could be rebased against upstream (so I wouldn’t lose PBC’s improvements to the codebase but could bolt on my own lexicon/UI), but I figured it’d be too much work to maintain long-term. In the end I decided to write my own frontend, and… Bluemoji still isn’t released.
At the very least it’d be a useful testing environment for new lexicons that are meant to interact with app.bsky’s. More meaningfully, it could possibly allow projects like Northsky to spawn their own derivative app infrastructure while still being able to track upstream improvements to the platform.
I think the web front end is relatively simple to build / host?
The hard part is perhaps how to manage PRs and other things?
And I guess this sort of ends up potentially like a maintained deer social. In that they’ve done some work in pioneering how to add custom features but maintain with upstream.
A lot of this setup feels like git workflows, permissions, and CI / testing flows.
For what it’s worth, BlackSky’s rsky (pronounced risky) has laid a of groundwork for this, I think? Might be worth joining forces for a greater good. FWIW I forked BlackSky’s fork of the front-end and I run it on my own little k8s cluster, it’s pretty neato. Risky’s a bit more involved but there’s a ton of work on relay, appview api server, etc there.
Edited to remove the direct reply, still getting used to the forum software.
I wholeheartedly support his. I really like rsky and have been paying close attention but while it started as a bsky fork has been completely rewritten to rust with a different goal in mind.
If we are to fork social-app, we’d need to do a little preplanning on how we can have your customisations/extensions on top without a heavy rewrite. ergo, ports and adapters so we could be adjusting bsky codebase to allow our features to sit on top and “activate” them with feature gates.
In the end it would be a community fork that would provide native support for certain community features that Northsky benefits from, encouraging the community to fork and work off of it so they’re not having to do that baseline work to get the app into a state they can really develop with.
For the appview, I spent some time setting it all up from scratch and the baseline changes are as simple as allowing the moderation did, domains, and feeds to be configurable. I think we could do with building out more references for indexers and how they can behave as while the basic one is simply “Take everything and feed it to the appview”, I’ve written one that helps to quickly backfill feeds by doing some elaborate discovery with microcosm.
I expect we’ll need to pull in some resource to lay that groundwork but I absolutely see this serving a real need for everyone.
The web frontend is pretty easy to host! I’ve setup a ton of stuff already in my maintained soft-fork of a fork of deer.social on GitHub at jollywhoppers/bitchsky-app.
Still need to replicate the process Bluesky uses to release builds on official mobile app stores. Also want to move it to a tangled.org repo, but that will requires more changes.
I recently purchased domains for a new name for the app & upcoming accompanying PDSes as well. Regarding Appviews, I hope users will be able to select their own out of a premade list or by entering their own chosen url.
The web frontend is easy to host (I got it running localhost).
Running CI, creating deployment-per-PRs for unique feature explorations, and keeping up to date with upstream and re-basing PRs is where the work is.
So, if I want to explore lexicon embeds with Semble, Smoke Signal, and Leaflet, I don’t have to maintain and run my own frontend, but can run lexiconembeds.COMMUNITYFRONTEND.COM just by creating a PR requesting that this get hosted for me.
Having a “baseline” modified front end that e.g. has the appview selector option, would also be part of this.
That’s the crux of it. We want the services to be easy to get up and running, social app is the easiest but appview infra takes some intimate knowledge as it’s serving multiple utilities and there aren’t very good explainers on the hydration process.
In the end, yes you want to have a container you can launch that only needs a few settings but when we’re looking at developing features/collaborating care needs to be taken so we don’t “develop ourselves into a corner”. I’m mainly speaking from a maintenance perspective where we’re supporting a community of developers who each have their own goal of what they believe is a good feature/enhancement so the sooner we structure it to allow flexibility the better off we are to maintain as stewards.
I’m Samantha and i’ve been working on Northsky’s social-app client the last few months.
I’d like to get things set up in place for getting more users moved over to using different appview stacks.
I’m excited to announce we’re going to begin work on the maintained IndieApp soon!
Here is our current road map this month:
UI Customization
In-app Moderation capabilities
i’ll keep this thread posted with updates and photos along the way!
