sunrise choir - 23/10/2018

Attendees

• Aljoscha
• mikey
• pie

Agenda

• checkin
• rfc: formal change proposals?
• state of bindings?
• private-box spec
• licensing stuff?
• merkle stuff?
• checkout

rfc

• alj: who decides?
  • is it whoever happens to implement it in sbot?
  • mik: governance!
• alj: don't care about format, as long as consistent
• mik brought it up in private thread:
• alj is close to making new things, so could use an rfc format soon
• mik: will be the case we need to hand-wave as we go
• mik: we have the social capital, as long as we are intentional with how we spend our social capital
• pie: hard to say no to working code and documented systems

state of bindings

Looking good.

private-box spec

• alj: pie you said you want to practice writing specs ;)
• pie: mik is this a good idea?
• pie: where do specs live, how should they be written?
• mik: alj made an mdbook, a rusty gitbook
  • https://github.com/sunrise-choir/spec
• mik: i made travis auto-publish to
  • https://spec.scuttlebutt.nz
  • https://spec.ssb.nz

spec in general

• licensed as CC share-alike
• alj: want to link to stable identifiers for concepts
• mik: structure is going to change anyways
• mik: glossary of all stuff you want to link to

licensing stuff?

• mik still needs to start the conversation
• new learning is Manyverse needs copyright assignment or something similar because it can't publish to Apple Store as (A)GPL
  • in publishing to Apple Store, they require you to accept a new license, which is incompatible with (A)GPL
  • solution is if you own copyright (or have it assigned to you), then you dual-license it to publish it under the store
• mik: i'm of the opinion that we should have a legal entity that owns all the Scuttlebutt copyright
• mik: barring acceptance by the rest of the community, i'm keen to have all Sunrise Choir copyright owned by some entity
  • keen for us to strongly defend the value we create
• mik: basically
  • keen to license under AGPL-3.0
  • also keen to have flexibility for future open source licenses and one-off proprietary licenses

merk(le|el) stuff

• alj: my plan was to let old feeds rot (but still supported)
• mik: keen to migrate old feeds, don't want to give up the cypherlinked library of knowlege we've accumulated
• alj + mik: we still haven't figured out how to migrate data without breaking cypherlinks
  • stupidly hard
• mik: i've been talking with dom about this since the beginning
  • latest convo: if we were to upgrade hash function, we'd publish a new message (say a message of type "upgrade:hash") that re-hashes the old message, then in the future when you reference the old message you use both hash ids
• alj: this seems like a protocol thing, not an application-level thing
  • messages are inherently application-level
• alj: see what ipfs is doing
• alj: with regards to using new feeds with old feeds, it can work if each server supports both, might be possible to use initial characters of old feeds to mark version, etc
• mik: can we retroactively add the merkle-structure to old feeds
  • can we maintain old hashes, signatures, etc for linking
• alj: hyper-core is a fun idea, but afraid it's not seriously an option
  • we have more meta-data than they do
  • and use different hash and signature multiformats
  • if we were tied to hyper-core, we wouldn't be able to add new protocol features that aren't already there
    • hash upgrades, signature upgrades, message dependencies, etc
• alj: current view is to have replication meta-data (what you need for security guarantees) to carry around a payload
  • then have a ssb specific payload inside (what you need for applications)
• alj: post-call-edit: Nope, my current view is that there are of three levels of data:
  • metadata relevant to verification
  • Type and Option\<Timestamp\> as the interface shared by all message content
  • actual content