# Cabal Community Chat #3
### 2018-11-12

### Participants
(feel free to add your own name here!)

* cblgh (the notekeeper this time!)
* nikolaiwarner
* karissa
* cinnamon

#### cblgh
* has been doing the kappa workshop as well and loving it
* thinks there might be a bug somewhere (either his code or multifeed-related)
* is going to keep working on the multi-cabal pr
* going to change modifier from alt to something that works on macs / PR neat-input to make alt work
* loves starting cabal without options and join all previous cabals automatically thanks to the new config file
* thought it would be extremely cool to create a **browserify plugin** to make all the network connectivity work in the browser (transforming network calls into websockets? webrtc?)
* is interested in writing a grant application for cabal for samsung zero grant
* had initial thoughts about how to foster sustainable work on cabal / how to handle money
* will attempt to do the following this week:
* work through the rest of the kappa workshop
* continue working on bugs in the multi-cabal pr
* help support documenting hypercore with cinnamon
* mentioned `/walkaway` to rekey a cabal's swarm key and leave the trolls speaking amongst themselves (thanks to noffle for the idea)

#### cinnamon
* is interested in documenting hypercore
* collaborative writing on improving hypercore documentation
* more on how it works, document its api surface, provide useful metaphors for it
* the endeavour is happening here: https://hackmd.io/AFhXnZ-3Q3KyAWp0ZbYgUg
* thought we should look at bumping protocol versions in multifeed and cabal-core to prevent old peers causing confusing errors
* due to the fixes noffle just implemented in multi-feed / cabal-core
* it's okay to do a major bump, we're still experimental
* **to noffle**: how do you feel about this?
* bugs can spread in 3 ways:
* different version clients connecting and misunderstanding each other
* old clients generating empty feeds and legitimately syncing those
* alternately running old and new feeds on the same disk database, so the new client picks up the bad feeds left by the old client
* we need to keep restarting the ecosystem to prevent the bugs from spreading

#### nikolaiwarner
* is feeling confident with developing thanks to the kappa workshop
* is going to look at fixing cabal-desktop soon
* was checking out push notifications for the mobile app over the weekend
* was really hard to do push notifications
* probably needs a dedicated peer / bot (for when the app is offline)
* simplest would be to do a local notification from the app necessitates running the app in the background all the time. this is probably where we start
* deltachat has push notifications and uses fdroid apk; but is hacky and in java
* 'if we can create a chat platform, then we can create anything'
* is going to look at getting the pr going for `cabal-client`
* wants to base the mobile app off of cabal-client

#### karissa
* went to aaron swartz day and presented on dat, mapeo. mentioned cabal and people were really excited
* thought about how to make cabal work for organizations/companies
* dedicated peers to rehost cabal for orgs
* using websockets to enable a browser version
* suggestion to fork soyuka's dat-daemon to support raw hypercore feeds
* dat daemon probably sends maps events to web-sockets and uses that instead of disco swarm
* kind of experimental still
* would be cool to use in cabal to enable web version
* life status update:
* wants to think more about licensing in general
* wants to move from fulltime software dev into working on allocating grants/funding for decentralization projects in general
* is thinking about starting dev again of cabal-irc
* create a connector for cabal <-> irc
* wants to help writing the samsung grant
* thought it would be nice to have someone with design experience look at http://cabal.chat with the goal of improving onboarding into cabal
* underExposed + cabal could be a good thing: https://simplysecure.org/underexposed/
* yosh + datrs
* [consent-swarm](https://github.com/karissa/consent-swarm): hey i want to replicate with you!
* a handshake for hypercore replication
* just a json object that's sent back and forth

### General
* hypercore might have a header that you can use to specify versions to allow you to reject incompatible
* maybe we should spend a few hours and improve the docs for hypercore/discovery-swarm/multifeed
* explain core concepts
* document the api
* good to know how we are supposed to use it, what it supports
* they call us the _**hypercore detective team**_ ~cinnamon
* idea: browserify -t use the plugin and then it works with websockets.
* [grants repo for cabal](https://github.com/cabal-club/grants)
* public cabals are currently low trust (they might break)
* cabal-web
* look at how dat-daemon works
* make quick prototypes _then_ look at integrating the promising leads into cabal
* make something hacky and quick for cabal:
* websocket server that looks like a bot in the channel
* user goes to http://cabal.chat/*public-key*
* js client creates it's cabal in the browser context (memdb or indexdb)
* js client replicates with wss://cabal.chat/*public-key*
* other peers that see the websocket server bot will also see js client messages
* webrtc
* complex
* no nodejs version (this might actually exist? https://github.com/js-platform/node-webrtc)
* used by webtorrent
* doesn't work for 10% (is this still accurate?)
* websockets
* better reliability
* we should use standard ports to circumvent port issues that scuttlebutt has had
* the samsung grant
* angle: the value of decentralization for poor internet; comms will still work for decentralized/distributed apps
* how do we do binary stuff in cabal? ideas below
* main message hypercore links to something else (a media message) that stores the blob/media/audio-videostream in a hypercore/hyperdrive (1 per file)
* would be nice to not grow on disk forever - want to be able to forget old stuff
* 2 hypercores, one for messages (which we have atm) + one for blobs
* media messages are links to other hypercores. cabal clients can have adapters for the different protocols (ipfs|dat|http|ssb)
* or use vanilla dats for storing media. one dat per media message - these can be individually forgotten by clients
* cabal could have a policy to keep dats around for a week or so and then remove them. adjustable per client. you could have a pub-style client with longer retention time
* blob hypercore is sparsely populated
* might need pubs? (cf ssb)
* if we use hyperdrive we can make it static (don't use live option)
* makes it content-addressable
* good for usecase where each media is represented by one hyperdrive (10 media messages => 10 static hyperdrive links)
* less overhead, less security risk
* we should look up what changes when we make it static
* 10 images and a video in one media message -> 1 hyperdrive
* how do we create a mvp?
* could upload to pastebin hehe
* spawn a static (`live: false`) hypercore/hyperdrive per media and link it in with peer's hypercore

### Links
* https://kappa-db.github.io/workshop/build/01.html learn how to build distributed apps via a text tutorial
* cabal was added to https://github.com/redecentralize/alternative-internet#messaging
* https://github.com/jimpick/dat-shopping-list
* https://www.npmjs.com/search?q=dat%20daemon
* https://www.npmjs.com/package/@dat-daemon/client
* https://samsungnext.com/whats-next/introducing-the-samsung-next-stack-zero-grant/
* https://github.com/jimpick/cabal-ses-bot
* https://simplysecure.org/underexposed/
* https://hack-the-beach.com/
* help us write grants for cabal https://github.com/cabal-club/grants/blob/master/samsung.md
* http://github.com/karissa/consent-swarm