Butt as a Service

i'm very interested in Scuttlebutt pubs as a service, so i've started playing with developing a system to help provision and monitor Scuttlebutt bots in the cloud. think of it as the #_hashbase of ssb.

GitHub: https://github.com/ahdinosaur/butt-as-a-service
ssb: %ddxU/I4...

here's my design spec so far:

job stories

• when i want to start a bot,
  • if i haven't been here before: i can register, setup a monthly payment, and name my first bot
  • if i have been here before: i can sign in
• when i come home, i can see a dashboard for my bots
• when i want to monitor a bot, i can see visual data about the pub service
• when i want to update the bot's status, i can stop or restart my bot
• when i want to update the bot's code, i can upgrade or rebuild from the bot's source
• when i want to export a bot, i can retrieve my secret, gossip, log, or blobs

design

landing

----------------
=  butt.nz
----------------
[start]

start

----------------
v start        x
----------------
- email
- password

[yes]

newbie

----------------
v newbie        x
----------------
welcome!

- name
- payment
- bot
  - name

[yes]

dashboad

----------------
=  butt.nz
----------------
- [my.butt.nz] #alive
- [your.butt.nz] #alive

bot: actions

----------------
=  your.butt.nz #alive
----------------
[**actions**] | [status] | [invites]

- [invite]
- [restart]
- [stop]
- [upgrade]
- [rebuild]
- [export]
- [delete]

bot: status

----------------
=  your.butt.nz #alive
----------------
[actions] | [**status**] | [invites]

status: alive
uptime: 100 days
disk usage: 10 GiB
bandwidth usage: 100GiB
memory usage: 100 MiB

bot: invites

----------------
=  your.butt.nz #alive
----------------
[actions] | [status | [**invites**]

- used
  - alice: ...
  - bob: ...
- unused
  - carol: ...
  - dan: ...
  - eve: ...

data

agent

• type
• name
• description
• service

belongs

• sourceAgentId
• targetAgentId

services

• public http server
  • /authentication/sign-in
  • /authentication/register
  • /agents
• private http server
  • /agents
• each person agent has many bot agents
• for each person agent, run
  • cloud compute
  • cloud storage
• for each bot agent, run
  • for each pub
    • docker service

modules

• public http server
  • feathers
  • feathers-authentication
• private http server
  • feathers
• cloud provider: scaleway
• cloud orchestration: saltstack
  • get config: salt.pillar.http_json.ext_pillar

progress report:

• wrote up design spec
• investigated cloud providers:
  • mid-term plan is to use Catalyst Cloud here in #new-zealand, but given how sbot is currently a cpu and memory resource hog, will start with something more affordable
  • short-term plan is to use Scaleway, with each bot on a cheap node
• investigated cloud orchestration engines:
  • got a Salt Stack master up and running, which pulls configuration from git repos
    • state (orchestration instructions) is provided by public repo: butt-as-a-service
    • pillar (private configuration) is provided by private repo: salt.butt.nz
• current goal is to setup @ssb.mikey.nz @ssb.rootsystems.nz and @one.butt.nz to run on this system

@Zach! how much would you be willing to pay for a reliable pub that you could invite your friends to?

oh nice, some competition! i wish you the best.

https://sunshinegardens.farm/

#bass

This is a fantastic idea @dinosaur (See I'm not the rapidly anti-enteprise person I clumsily presented myself as in another thread!)

I looked into getting a VPS to set up a pub myself but balked at the $5 a month minimum as right now my partner and I are very short of money. That said something your service at $5 a month also gives me is the assurance that someone I trust ethically and technically is running it so I think I could find a way to carve that out of my budget somewhere.

hey @mikey I love your ascii designs! It's got me seriously thinking about whether we could do that.

Here's a radical idea - you don't put any of that interface on a web server - you put it all on the buttz. i.e. once a bot has owner(s) established, it just issues status and commands through private messages. This way anyone can build interfaces .... and we're role-modeling apps.

Notice if you go this way, the buttz becomes your easy notification layer if the pub need to tell you anything important has happened.

In reality, a hybrid is probably practical, but perhaps the challenge is what if we built butt-first?

p.s. I would love to volunteer as a tester too. I'd pay $5-10 for this service, and might run 2 pubs :

• mix.butt.nz - my personal buttz
• proto.butt.nz - my more business facing / community hosting buttz

I'd also love to do a whiteboarding session on any topic which is useful - basically pairing on anything that will help this success. I'm very excited for it to exist, and especially pumped that it's you building it.

@mix yeah i was thinking about butt-first: using the butt as a database. i actually realized it wouldn't be that hard to do with feathers.

at the moment i mostly need help grinding some Salt Stack configs until i get the core infrastructure working from a static config. @nichoth i'm just making things up, have played a bit with Salt Stack before.

also to set expectations, i'm playing with this meow because it's some good holiday distraction, but i don't expect to have anything for public consumption until after spending actual work time on it, probably sometime after April when we release Cobuy.

I've thought about ssb as a service as well, but then I get confused by the seeming contradiction of using centralized services to host a p2p network.

@nichoth yay complex systems! i don't want a single centralized #ssbaas provider, everything here is open source, i want to make it easy for technical humans to be their own #ssbaas providers, so they can make it easy for their non-technical friends to host their own pubs.

we can hold hands and sing the praises of decentralized systems, but then why isn't everyone hosting a pub? and i can understand, hosting a pub is not easy! i'm still trying to get sbot to reliably run in spite of crashing and infinite looping. i want #ssbaas providers and pub admins to be real people and groups with real faces, not some faceless smart contracts.

am i remembering correctly that there is an ssb client in python somewhere?

anyway, @mix got me thinking again about grid. i'm a little bit concerned about sbot being too heavy to work as the backbone of a p2p scheduler esp on smaller devices like an rpi zero w, but maybe some kind of delegation scheme can be worked out so only the bigger machines have to run an sbot.

the basic idea is something like plan 9 or kubernetes that is managed over a p2p mesh so you can link all of your computing activities into a single activity stream that many different applications can consume. "data convergence" rather than "ui convergence".

sunshine gardens (server) farm is my testbed for grid so let's hope i can make it scale

the really exciting part is when you bring together git-ssb and something like grid, you have a fully decent pipeline for developing and deploying applications. making the ui/ux nice enough for average user is another big project, but getting all of the lower-level bits working for developers is an important first step.

excuse the messy wiki, my notes are in too many places at the moment and i'm working on consolidating everything to a single location.

progress report

may have finally sorted out how to reliably run a pub!

have been having problems with two cases where sbot goes unresponsive

• sbot ventures into some infinite loop that tries to do everything at once

• sbot dies but is left alone

(screenshots of Digital Ocean droplet monitoring for @ssb.rootsystems.nz, 1 GB mem, 1 vCPU)

i updated ssb-pub with:

• a health check: sbot whoami
• instructions for how to use healer to automatically restart unhealthy containers

so far so good, i think it's already restarted some unhealthy containers, keen to see how this progresses.

oh and salt stack, butt-as-a-service with associated private config works on a Scaleway server, right meow configuring salt itself!

next steps are to

• for each day, check in on the pubs, are they staying alive?
• butt-as-a-service
  • for each hub bot, provision a server with Salt Cloud
  • for each pub bot, setup ssb-pub docker with Salt on the hub