Skip to content

Latest commit

 

History

History
102 lines (83 loc) · 4.99 KB

04-21feb2018.md

File metadata and controls

102 lines (83 loc) · 4.99 KB

dat protocol WG (#4)

21 Feb 2017 via IRC (#datprotocol)

Agenda discussion

People

  • Bryan
  • Paul
  • Joe
  • Mafintosh
  • Tara
  • Danielle is in the background listening :)

Agenda

  • PAUL nomenclature questions
  • voting on DEP 0001 into final status
  • voting on hypercore DEP into draft
  • multiwriter API ergonomics

Summary/Review of meeting 3

Meeting notes

General Notes

  • Decided to use "Hypercore feed" in last meeting
  • dat protocol connection terms; channel vs feed
    • 'channel' is part of the wire implementations
    • Channels on the wire can be reused by other feeds
    • channels are way to multiplex connection
    • TABLED for discussion in DEP
  • peers connected terms; syncing, connected, swarming, seeding, etc.
    • how is seeding used in BT
    • syncing, connectecd, swarming, seeding
    • when you join the discovery network and transact with lots of peers, youre 'swarming'
    • when two peers connect, they 'sync' the data
    • the state a client can be in when it's "done synchronizing", but it isn't actually done and is waiting for potential new versions
      • "actively idle", syncing but idle
      • the distinction between the writer, which could be said to be "seeding", a peer only downloading most recent and stopping ("replicating"?), and a persistent peer ("swarming")
    • be explicit about different states
    • propose that a persistent peer is "seeding" whether they are the author or not
    • there's the distinction between the writer, which could be said to be "seeding", a peer only downloading most recent and stopping ("replicating"?), and a persistent peer ("swarming")
    • the action between 2 connected peers ("sync" ?) the action of being on the discovery network and syncing ("swarming" ?) the action of being a persistent peer ("seeding" ?) the action of a temporary peer that partially replicates (?)
  • "entries" within a single hypercore feed name
    • in the hypercore DEP, I've called them "entry"
    • and I've call the numbers "revisions"
    • mafintosh calls block, because its atomic unit of system
    • consensus towards block
  • revision, index, etc: numbering system
    • index
    • revision ("rev")
    • sequence
    • with multiwriter it might be 'revision' for one feed and 'revision vector' for all
    • feed numbers are unresolved, looking at 'revision'
  • there is a bit of nomenclature ambiguity whether SLEEP means individual files or the collection of files hypercore uses
  • multiwriter, hyperdb + multiwriter is one go but integrating it will be two
    • one pr to that add hyperdb single writer. Another one that exposes multiwriter
    • first PR to hyperdrive will have no backward compat at all then discuss from there

Decisions Made

  • defer on name of hypercore feed __s (block vs entry) pending discussion/thinking
  • defer on name of 'revision' or 'version'
  • defer on voting of moving dep 0001 to final state

ACTION ITEMS

  • pfrazee, mafintosh, bnewbold will discuss channel nomenclature as part of work on DEP (@pfrazee, @mafintosh, @bnewbold)
  • discuss syncing/seeding/etc in nomenclature DEP - jhand will formalize terms that need definition (4 terms?) (@joehand)
  • hyperdb -> hyperdrive PR (@mafintosh)
  • "how do we roll out the breaking change" via hyperdb/hyperdrive
  • Next Meeting Setup (07 March, 9:30 am PST)
    • Setup issue for agenda items (@joehand)
      • agenda item: decide on block vs entry discussion
      • PUNT: nomenclature ambiguity whether SLEEP means individual files or the collection of files hypercore uses
    • Automate meeting prep (@joehand)
      • Checklist for prep/agenda stuff (@joehand)
      • Make template for notes (@joehand)

Existing Action Items TODO

  • DEPs
  • Other
    • Network Uptime Improvements
      • IA host DNS server (@bnewbold ping maf about it)
      • Prototype DNS -> Hyperdht