-- Leo's gemini proxy
-- Connecting to ix.cyb.red:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
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.
bbnet's ui is built around a grid of hexagonal tiles? these are vector-based tiles that can easily scale to any size display.
simple 9-color themes
tracker 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 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
twtxt
secsb -> tcp/ip
chatfs -> xmpp -> tcp/ip
deltachat
chronochat -> ndn
simplechatfs -> irc -> tcp/ip
sms/silence
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.
users are meant to compose and share their own interfaces and to modify the system. as such, we intentionally limit the ability for the application developer to "innovate" with the interface aside from sharing a screen layout. system and application themes, even generated themes, are easily and automatically available as a result. the hope is that the visual and behavioral consistency will make the unsusal interface more approachable.
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.
i would like to generate UI elements from simple and terse scripts that describe them!
a stream of text and a list of members, what else? (inc uwu emoji obv)
-- Response ended
-- Page fetched on Fri May 17 09:39:09 2024
