Brightsun is building on the AT Protocol used by Bluesky, and using much of the Bluesky codebase for its apps and services.

Since AT Protocol is open and decentralised and supports federating user content, the generally expected approach for developing apps or communities is to build on and integrate with the existing public services provided by Bluesky PBC and increasingly by other groups such as Blacksky. This creates a web of content that can be distributed and interacted with throughout the "Atmosphere" (the ecosystem of interoperating apps and services built on AT Protocol).

Brightsun is currently not integrating with the broader Atmosphere, which might be surprising... The reasons for this are:

• We're still experimenting with producing more focused social networks. In its early days, even Bluesky didn't yet allow federation; we'd like to grow more and define our own approach before seeing with federating will be of benefit for our use case.
• Our different mentality about what is or isn't harmful is quite different. While many large social networks, including Brightsun, have policies that lean towards not blocking content unless it's actually illegal, we'd prefer to create a space that is more specifically curated based on our values as reflected in the terms of service.
• We'd prefer moderators not to have to engage with content that is illegal or border-line illegal; the potentially disastrous impact has been documented in numerous places. We hope that setting narrower boundaries will help with this.
• We'd like our users to be able to have a focused experience without other content accidentally drifting into this space. Connecting to the broader network may allow more interaction but also mean less focus

Brightsun Architecture

Brightsun networks duplicate most of the stack run by Bluesky.

The above diagram (based on one from Martin Klepman and Bluesky's Architecture paper) shows the Bluesky and Atmosphere components, with added examples of parts run by Bluesky PBC as well as those run independently. This interactive version allows you to turn on and off various layers (for data and protocols, software and domains) or tags (for alternate lexicons, bluesky-owned items or external items).

This modified diagram (interactive version here) shows how Foodios duplicates the key elements of the Bluesky architecture, but runs its own version of them (in yellow). Note that Foodios is running its own PLC (public ledger of credentials), so that references to PDS user repos are not automatically drawn into the general Atmosphere. However, since the keys for a distributed identify are what define the account, it will be possible to join the public PLC at plc.directory at some later point if that is desired.