Skip to content

Latest commit

 

History

History
125 lines (115 loc) · 6.28 KB

01-09jan2018.md

File metadata and controls

125 lines (115 loc) · 6.28 KB

dat protocol WG

09 Jan 2017

People:

  • Mafintosh
  • Joe
  • Paul (Beaker)
  • Tara (Beaker)
  • Bryan (IA, not in official capacity)
  • Danielle
  • Karissa

Proposed Agenda Items (proposed during call)

  • RFC for core protocol changes
    • Research other RFC processes
    • Report back at next call?
  • How do we decide who has accept PRs permission in the core repo(s)
    • More formal process needed for big things, as bad changes can be ... v bad
    • What should this process look like?
    • Story for who has what permissions today?
  • Unifying/organizing where the docs are and how the project delegates adding/changing
    • (Discussed, moving most to datprotocol org with some exceptions)
  • Moving to support new version deployments
    • Moving window of support?
    • Put a version number in protocol stream (part of a RFC)
    • Main decision - do we want to enforce a migration strategy in RFC? Or is that too high a burden?
    • Require note that this is breaking, what libraries/layers break (Rust, example)
  • Need to address some issues with connectivity (failure to connect rates at 25% in Beaker)
    • Find out when we can get on priority list and get it done
  • Dat.json file (?? - where does this fit)
    • RFC - dat enhancement proposal

NOTES!

  • Idea bi-weekly call. In the future it can be a public hangout. This first one is private.
  • Idea: Protocol working group, can be fluid but should have same core
  • Call to discuss what is missing from protocol
  • More formal process for what can be added, more transparent process
  • Goal: seen more as an organization and less as a group of informal hackers
  • Should have an agenda every time
  • Mathias - wild idea that we stream this on Beaker =)
  • (Introductions for Bryan + Danielle) - Bryan participating as an individual, not as IA employee
  • Need to catch up documentation on new changes, hyperdb, etc.
  • Also is whitepaper and should RFC just be PRs to whitepaper
  • Formal documentation for implementers
  • Many different sites for information (dat protocol, docs, whitepaper, repos, etc.)
  • Each meeting "Big Priorities" list (what is the biggest issue you have right now)
  • Time limit on meeting (? - yes an 45 min - 1hr)
  • What is the best way we can get work spread out to everyone + decisions?
    • Get RFC process going without having to wait 2 weeks
    • Any missing docs, etc. - get those kicked off now
  • There should be two doc repos (datproject.org, beaker)
    • Keep using datproject.org as main place for all Dat stuff
    • beakerbrowser.com/docs - they plan on doing a big push in next few months on docs
      • (also web specs repo - in beaker) - collect resources for anyone that may want to implement in browser
        • Seems natural for this to go in the same place as RFC
  • Things:
    • RFC
    • Dat Docs
    • Beaker Docs
  • Extraneous things:
  • Docs could be separated into technical vs user:
    • Dat Protocol - implementation, protocol, RFC
    • Docs.datproject - user oriented, funder oriented
  • Whitepaper is not substitution for spec
    • Holes in whitepaper right now
    • Need a spec alongside the spec - whitepaper is more static thing
    • PDF is more a snapshot in time, harder to change
  • Bittorrent.org is nice because it has for users, for developers links
  • Can be confusing if spec is changing rapidly
    • needs to be versioned and should be clear what things are using what version
  • Put protocol spec in RFC system (similar to bit torrent site)
  • PROPOSAL:
    • dat protocol has all the spec stuff, no software
    • ? Are docs.datproject going to move? No
    • RFC stuff gets published on dat protocol
  • Protocol website should mostly be for people implementing or trying to improve protocol
  • Concern for having documentation in many places
  • Two things for webspecs:
    • What browser is supposed to do (implementation specific)?
    • What APIs are required to be implemented?
    • On docs.datproje.orrrgg - something for people writing JS in browser
    • docs.datproject.org = using dat software
    • datprotocol.com = specs, rfc
  • Beaker has informal RFC system (https://github.com/beakerbrowser/specs)
    • Been doing it mainly for Beaker-specific decisions
    • Should they continue to keep it separate from Dat Protocol RFC?
    • Ask if they should be in web specs list (Should it move to dat protocol org)?
  • What other RFC process exists, can we look at examples

Follow Ups (Action Items)

  • Agenda for next meeting (JOE - start a new doc/issue for agenda proposals. Submit by (?- date))
  • Time for next meeting (MAFINTOSH: this time - 9:30PST Wednesday, mafintosh will share schedule next one)
  • Put these notes up on a repo (JOE: Dat Protocol organization repo; meeting notes)
  • Move whitepaper to Dat protocol organization, static repo with readme for RFC (JOE)
    • BRYAN will rip out new stuff from the whitepaper so we can freeze it
  • Datprotocol.com site (WHO?? simplify, replace) (JOE can start)
  • Create RFC system and publish on datprotocol.com
  • Research existing RFC processes and find example (BRYAN)
  • How do we decide who has accept PRs permission in the core repo(s)
    • Move to next call? (discussion can happen in RFC process repo issues)
    • Time for a more formal process (in Danielle's opinion)
  • Make a datprotocol/repo for meta process (JOE):
    • meeting notes
    • agenda
    • Bryan RFC process research
    • Misc. organization issue discussions, etc.
  • Network issues:
    • Need deterministic bug and integration testing via mininet (PAUL - create repo + share w/ mafintosh)
    • Once there is failing integration tests, mafintosh can help fix/diagnose
    • Where do integration tests live (org/repo?) - datprotocol/integration-tests