Agenda
- checkin
- updates
- spec check-in
- Mix's PR
- CFT's test vector(s) https://github.com/tinySSB/tiny-ssb-spec/tree/goset-test-vectors/test/goset
- May spec plan
Nanomonkey
- fried the power chip on my new T5 D:
- not sure exactly where the damage is, likely battery management chip.
- working on replacing parts / re-ordering
Mix
- playing with a Meshtastic device, reports about reach
- learning about noise, the community has gone to ShortFast to handle too many peers
Question
- how do we review?
- a) details
- b) language
- feed vs log
- packet / message / vector
- what's the message? --> why not use "payload" instead of message?
- payload vs content
- from networking: a packet has fields, one is the payload field
- test vectors?
Other topics discussed:
- lets work more async
- in person meetings are not being used that effectively
- idea: try to post work 3+ days out from meeting, ask for a review
- idea: move to actively using more written / async comms, giving time to process
- tour of Github PR features
- how to reply inline
- "resolving" inline comment threads
- viewing a preview of MD files
- test vectors
- CFT presented formatting
- we discussed where we might put them => ultimately in the spec repo
- for now, work in github issue while spec settles down
- idea for order we produce them
- review spec, use this to map "stepping stones" where a simple test-vector could help ensure a person building following the spec could benefit from confirming their logic
- add these "main paid" test-vectors
- add more complex test vectors (e.g. edge cases, fully worked scenarios) as required later
- Nanomonkey and CFT will review Mix's PR, and give comments when each is able (CFT is in the middle of Finals)
- CFT will do a first pass of test vectors, working on the initial message packet, and then later will work on producing "scenarios" of back and forth between peers