You are reading content from Scuttlebutt
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@SoapDog (Macbook Air M1) %2MxVomhw0ie7pETGs4G6p4NMy6XMYfEz0OnsbXTBHkU=.sha256

There was someone here working on a GraphQL server, I remember seeing an alpha during Scuttle Camp One. I don't remember who was working on it though.

I'd long advocated for a daemon approach, that is what I tried to do with Scuttle Shell. One daemon to run the SSB platform, and clients connect to it.

@andrestaltz %nRvdi87wMByAWxiCON2IdqOfEXu3MZbAGl3ycIvTVT4=.sha256

In private I encouraged Dave to go ahead and do this. It would be pretty simple overall and quite a useful thing for the community. Useful for Patchfox too, I suppose?

I think sunrise choir did a GraphQL server, right? And then there's Ahau's Apollo-based GraphQL server. But in practice this could be "sbot 2.0" or something else you want to call it, and it could be just an HTTP interface to a secret-stack installed with "all plugins" you can think of, running on localhost. In my extremely rare spare time I can help with this.

If I had the time, I'd just npm install gqtx, express, secret-stack, ssb-db2. First set up the SecretStack instance in a way very similar to Manyverse's src/backend/ssb.ts and then hook that up to gqtx and express via some GraphQL schemas. The server should run only on localhost, not to other computers, for safety. And maybe as an additional safety mechanism, you could initialize the server with an access token as a CLI option, and then frontend apps need to use that access token as auth on the endpoints.

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@SoapDog (Macbook Air M1) %dqNi6eLMh37irab3rKAXKRSgPEdbcGnJ3YWUtP3XHxI=.sha256

@Dave [ macOS ] I understand. I was not giving you a map on how to do it. I was just mentioning that others here feel that this is a good project to invest in and that some people tried that before.

I'm totally sold on this project. I think it should be done.

What I failed to mention is where Scuttle Shell failed which will be a challenge for this project as well, which is deciding on which plugins to load. The problem is when an app expects the same plugin as another app but with different semantics, which was the case of Patchwork vs The World and in the end made Scuttle Shell adoption hard.

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@andrestaltz %F4L8G+2EXG2yYKA8FP/iiZPOnchCGsCRL5MviwhC3OE=.sha256

The problem is when an app expects the same plugin as another app but with different semantics, which was the case of Patchwork vs The World and in the end made Scuttle Shell adoption hard.

@Soapster is right here that this is the core issue with such sbot 2.0 idea (can we call it ssbot pretty please?). But I think we can this time approach it as not being a "god daemon for all apps", it can be an opinionated toolkit to build some apps. This is much easier now if we go with "there are many ssb folders". So Manyverse desktop can use its own folder (and its own sbot), Planetary on macOS (via whatever iOS emulation) can use its own folder, and ssbot can use its own folder for all the apps it is serving. And I'm confident that this year we'll figure out app-to-app bootstrapping which will make ssbot not a requirement.

So this means we don't need ssbot to be a consensus layer for all apps, just some apps. Thus it could be opinionated and have only some curated plugins. And on the other there could be alternative sbots out there, e.g. one based on go-ssb for instance.

User has not chosen to be hosted publicly
@SoapDog (Macbook Air M1) %4Csft3jQXK6nzCOgN3L3NSWwQaR4WXu/IosnBY1KqAk=.sha256

What worries me about this is the maintenance efforts to be split because of different interests.

Err, that is a non worry. Most SSB apps are developed by very small teams, some of these teams are composed of a single developer. There is nothing to split. Build it and sprout a community around it. Don't worry about the current apps and teams. There are more developers in the SSB ecosystem than the current group of people working on SSB stuff. Those people will benefit from your server. There is nothing preventing current SSB developers from starting a new client using your server either. They can keep maintaining their current project and start a new one for the kicks.

Go for it.

PS: speaking as someone who starts new toy clients every now and then...

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@cel %WHz3JXyhqG0CPyoATdlpulrhwsx+dugffoJ5XUdrC/w=.sha256

GraphQL SSB server and ssbot both sound good to me.

~dtBy %WqhFCsr...

There is no "standard" filesystem layout for persistence of vetted SSB log messages. It follows, then, that there isn't a standard way to access arbitrary persisted SSB messages across clients.

The Flume architecture https://github.com/flumedb/flumedb#architecture and flumelog-offset format https://github.com/flumedb/flumelog-offset#format originally implemented in JavaScript, was ported to Rust: https://github.com/sunrise-choir/flumedb-rs#architecture

There is also a C implementation of a flumelog-offset reader: flumecat %NB+ufIk...

In ssb-server before ssb-db2 (i.e. as used in ssb-server currently, and in frozen Patchwork et al.), messages in the flumelog are by id in a hashtable file: https://github.com/flumedb/flumeview-hashtable#flumeview-hashtable
A reader for that hashtable format is implemented in C: ssbget %JB7GoEW... - that can read messages from ~/.ssb by id without a ssb-server running.

If some implementers want to use different core implementations coordinated at the filesystem-level, I think flumelog might still be a viable approach.
I wonder if it may even be possible to port ssb-db2 https://github.com/ssb-ngi-pointer/ssb-db2#ssb-db2 back unto the original flumedb, by altering jitdb https://github.com/ssb-ngi-pointer/jitdb/#jitdb to use flumelog-aligned-offset https://github.com/flumedb/flumelog-aligned-offset/#flumelog-aligned-offset and JSON instead of async-append-only-log https://github.com/ssb-ngi-pointer/async-append-only-log#async-append-only-log and BIPF. Then ssb-db2 indexing might be possible without a ssb-db migration.

User has not chosen to be hosted publicly
@andrestaltz %4gEwFHc140gWkX5yFHWVug/oIeHiozkdv10RWD2yZR4=.sha256

The Lord have mercy on my soul spare time, look what I made so far

Screenshot of GraphiQL showing a query for SSB messages

That said, @Powersource (phone) noted that

i think making a good graphql api takes more than just essentially exposing the json. Your queries should be able to look something more like:

post(id: ID) {
 id
 author {
   id
   avatar
   name
 }
}
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
Join Scuttlebutt now