Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2020.02.04-08:00pm UTC-0 | next datdot sync #27

Closed
serapath opened this issue Jan 29, 2020 · 3 comments
Closed

2020.02.04-08:00pm UTC-0 | next datdot sync #27

serapath opened this issue Jan 29, 2020 · 3 comments
Assignees

Comments

@serapath serapath pinned this issue Jan 29, 2020
@serapath serapath changed the title 2020.01.30-08:00pm UTC-0 | weekly partner meeting 2020.01.30-08:00pm UTC-0 | weekly meeting Jan 29, 2020
@jam10o-new
Copy link

jam10o-new commented Jan 29, 2020

didn't catch y'all online if the call did happen - either way I guess I'll put a status update here and we can discuss it async, I guess:

haven't committed anything this week and my next two days are pretty much blocked, but I did have some solidification re: attestations, shouldn't need much update to api, other than maybe adding additional parameters to register attestations (for specifying registration of friends, if we want them to participate onchain at all) [correction/edit: friends should only need to register if they need to be reported, I think that this would need an additional vec in the storage value I describe below]

Weekend plans are figuring out if what Nina has been seeing is a bug - it's another off-by-one at worst - but in my ad-hoc testing in the apps UI I haven't been able to replicate it yet. After that is done, finishing off the hash types (blind until we have some reliable challenge response attempts, which is why I'm prioritizing the potential bug in challengeMap first), and then finally finishing off the first implementation of attestations.

Specifically: I have attestations as a tuple of two vecs which represent "required attestations" and "seen attestations". Anyone can make an attestation and be added to the seen set, but only once every required attestation has been added to the seen set are the votes of the required attestors counted and the challenge resolved based on the majority of them. I think I'll emit the state of all attestations as an event before clearing it from state so it can be reported to the UI - feedback welcome on format and info that would include.

things that might need clarification/context: the bug: seemingly we're seeing a challenge in the challengeMap with selectedUserIndex, challengeIndex set to 0 - this challenge is for the pubkey 0x0....0 (which is obviously invalid), chunk 0, with a deadline of 0 blocks. This should not be a possible/valid challenge.

@jam10o-new
Copy link

would probably be worthwhile to concretely determine what the blockers are for calling something a good "v1" next meeting.

@serapath serapath changed the title 2020.01.30-08:00pm UTC-0 | weekly meeting 2020.02.04-08:00pm UTC-0 | weekly contributors meeting Jan 31, 2020
@serapath serapath changed the title 2020.02.04-08:00pm UTC-0 | weekly contributors meeting 2020.02.04-08:00pm UTC-0 | next contributors meeting Jan 31, 2020
@ninabreznik
Copy link
Member

Quick short notes:

Updates

Other

  • try to use linter
  • contact Dieter (Web3 foundation grants)
  • make DatDot dictionary (hosters = dotters?, backers? etc.) => let's then together discuss
  • Encoding/decoding math
  • Docker
  • Dashboard (get in touch with @substack)

@serapath serapath changed the title 2020.02.04-08:00pm UTC-0 | next contributors meeting 2020.02.04-08:00pm UTC-0 | next datdot sync Feb 5, 2020
@serapath serapath closed this as completed Feb 5, 2020
@serapath serapath unpinned this issue Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants