# PeachCloud & scuttle-go

_10:00 UTC+2_
_Tuesday, 11 October 2022_

**Attendees**

- glyph
- boreq

-----

**Questions for Discussion**

What is required for PeachCloud to run a pub based on scuttle-go?

- Feature additions to scuttle-go
- Invite system
- Create
- Accept / use
- EBT replication woohoo
- Auto-magic connect with other room members? (other auto-magic?)
- Any other necessary features still to be implemented?
- Wrapping scuttle-go
- Go code that wraps the scuttle-go library and allows it to be run as a daemon or CLI tool
- What are the options here?
- Query interface
- How can the scuttle-go daemon be queried from PeachCloud (using Rust)?
- Is there some sort of minimal MUXRPC interface?
- Which methods will be exposed?

**Notes**

- acts as a client
- standard library of ssb code
- might use rpc layer to a separate repo
- application-level code
- pub has some extra code on top of this
- e.g. updating the social graph based on contact messages
- two programs with a lot of shared code: node vs pub
- service/domain code is largely the same
- flesh-out the code in the main repo first
- separate client and pub
- one week away from a test on a phone
- added some basic ebt
- no real docs on how it's supposed to work in ssb (implementation specific)
- can connect to peers and get messages (ebt.connect)
- doesn't currently implement caching etc.
- lack of specs is a big problem
- advantages: lowever overhead (not having to start so many streams), data is more compact
- disadvantages: can't just ask for friend feeds first
- wrap up of features first and then clean-up and think about how to run a pub
- previouly: predefined read / view models
- planetary has always used sqlite (complicated view models); put all the messages in there
- separate read model which is client-specific
- simple db stores all messages; gets contact messages etc.
- go-ssb: receive log (each new message gets a new id, ever increasing)
- scuttle-go will just have a pubsub (for reindexing etc)
- db stores messages, feeds (lists of msg ids), read model for social graph (needed for replication), list of pubs, tries to identify blobs

- next steps
- split codebase into 2 separate implementations
- pub
- client node
- 95 percent will be the same
- don't want to make a mess with feature flags
- also separate the library

- rest api for pub

- a single application could foreseeably serve multiple pubs
- e.g. spin up 3 separate pubs

- list of things that are needed for peachcloud
- share this with boreq