⚠️ MEMETIC HAZARD ⚠️
programming for the next billion
every (chat) app sucks because engineers think they need to build your interface for you! bbnet takes a different approach: here you can create and share virtual spaces that work however you need them to, over whatever protocol.
some chat networks have terms of service which prohibit third party clients, so these won't be possible to support (*cough* discord).
there *are* reasons that engineers do the UI work and end-user programming is far from a new concept. bbnet is simply anoher take on the idea. the focus on messaging puts human connection and collaboration at the forefront of the project. hopefully, this will yield something interesting.
this section gets pretty technical. feel free to skim the details. the important thing to grasp is that bbnet defines a set of internal filesystems that ui widgets all know how to talk to. behind the scenes, these filesystems know how to talk to the fedi and other networks. when a new protocol is added to the list, you can just sign in and start chatting without changing your screens.
specific functions (inputs, chat log), which are either native elm components or lain scripts, are applied in useful ways as a widget. a widget is a standardized wrapper that connects components to the application state through typed filesystem ports. the filesystem programs then map requests to the network level using a protocol driver. there is some complexity here, but it buys us a few important things.
- widgets only have to be aware of a few internal protocols
- protocols can be grouped by capability using the fs type
- bbnet can gain protocol support without changing end user scripts
components -> widgets -> filesystem -> protocol -> network
socialfs -> activitypub -> http
secsb -> tcp/ip
chatfs -> xmpp -> tcp/ip
chronochat -> ndn
simplechatfs -> irc -> tcp/ip
documentfs -> etherpad -> http
git -> tcp/http/ssh
this is clearly geared towards graphical messaging applications. luckily a large portion of the problems that software solves are communication problems. using these building blocks and other filesystems that aren't listed here, the capabilities of the graphical environment could be extended drastically.
remember that this is an experiment.
the sigils provide a simple vocabulary for referencing people and data within a distributed mesh network. these symbols allow users to annotate documents with opaque context which can only be resolved subjectively.
getting started with gemini
avi chat will only be supported by some networks because your client needs to exchange background messages with other clients so that avatars can interact. bbnet wants to be a good citizen of the network it communicates with. within the scripting environment, each channel is annotated with a type that indicates what features it supports. while there is no way to explicitly prevent a component from being impolite and lying about its capabilities, the typed interfaces at least allow end users to confidently assemble well-behaved interfaces.
- typed interfaces
- typed widgets
- typed high-level functional components
the runtime environment is highly constrained to allow easy composition.
(add (sub 5 3) 2) ; Basic Math
(λ (a b c) (concat a b c)) ; Lambda
(def obj:foo "bar") ; Creating object
(obj:foo) ; Reading object parameters
(def _sidebar (ui:create "sidebar")) ; Creating UI elements
a stream of text and a list of members, what else? (inc uwu emoji obv)
bbnet will often be constrained by the limitations of the networks it is interfacing with. to work around this limitation, without being rude, we propose operating a gossip network behind the scenes that can be used to replicate any information that can't be sent transparently over a given channel.
discussions toward radically sustainable computing
Donate with fosspay