Understanding design decisions

[rhz]

Hi everyone. @TDiazT and I are exploring the development landscape of scuttlebutt code and are interested in what you all are doing with Rust here. In particular, we believe the cool feature that the system should have a responsive ui even when downloading and indexing lots of feeds is super important.

To understand the state of development at this time, we would like to ask you a couple of questions about the design decisions in this repo.

1. Why do you use the the scuttlebutt server written in go instead of what you've written in rust like ssb-boxstream? What parts are not ready, if any, to write a scuttlebutt server in rust?
2. Why do you write a frontend in kotlin for this android app instead of using manyverse's frontend code?

Thank you all for the great work you're doing.

[cryptix]

I can only answer questions about 1)

What parts are not ready, if any, to write a scuttlebutt server in rust?

AFAIK at the time of writing this PoC, the rust ecosystem lacked a fully functioning feed database (ie the equivalent of flumedb/ssb-db(2) in rust) and thus my Go code was chosen as a stand in. The binding is fairly slim shallow tho.

[rhz]

I see. Thank you @cryptix! Do you know if the rust ecosystem at this time is still lacking a fully functioning feed database?

[cryptix]

@rhz right now: yes. but I'd ping @staltz about this who worked on ssb-db2 over the last year, it's just the rust port was scrapped because of time constraints but I believe the the design is sound and probably could reuse the test coverage, too. If your willing to work on this, I'm sure he has a task or three to hand over :)

[staltz]

Oh I didn't know about this issue, I wasn't watching the repo. Thanks for the @ cryptix

On question 1, I don't know sunrise choir libraries closely, so I can just assume. I think the database was covered by SQLite, if I remember correctly, and there was GraphQL involved. If you'd like to build something similar to ssb-db2, bear in mind it took us ~3 months and lots of bug fixes, but the parts are essentially (from lowest level to high level):

• BIPF (should be easy to convert to Rust)
• async-append-only-log (just a append-only log module, essentially like flumelog-offset but without flume)
• JITDB (bitvectors, essentially)
• ssb-db2 covers: read/write API, leveldb indexes, private message indexes

Why do you write a frontend in kotlin for this android app instead of using manyverse's frontend code?

I like Manyverse's frontend code, obviously, but I think it's not well suited for just plugging into another backend. It's very complex, and written specifically for muxrpc with nodejs-mobile (if I recall correctly, sunrise social doesn't have muxrpc), not to mention that my framework Cycle.js unfortunately scares some folks.