Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Michiel de Jong
    @michielbdejong
    Weekly brainstorm meeting starting in two minutes from now! :)
    --- Start Meeting Notes ---
    Present: Navid, Michiel
    Angus and George are arriving at the Ponder Source office
    Michiel de Jong
    @michielbdejong
    Present: -Navid, +George, +Angus, +Triantafullenia
    Since Navid's Jitsi connection kept restarting, this meeting is in-person at the Ponder Source office in Utrecht
    Michiel de Jong
    @michielbdejong
    George gives an update of where they are with timeld, and what they need for next steps.
    The cli has been refactored towards having a gateway
    Experimented with fly.io
    It's like Heroku but better
    With the rest API we will have to have a leadership election
    Michiel: unless sync is idempotent?
    George: I'm hesitating because the application API doesn't get told what the message ID was
    But you could deduplicate on transaction id?
    Michiel de Jong
    @michielbdejong
    But the operations in the other system would have to be both idempotent and commutative
    If the timesheet is append-only then it's fine
    In this application, relying on system clocks is probably fine
    Maybe push to a log / queue (event based)?
    Michiel de Jong
    @michielbdejong
    The content of the message is not 'this is the current state', but 'please apply this update'
    George: I'm trying to avoid having a conversation with the remote system, it's easier to build it such that m-ld always wins. :)
    Michiel de Jong
    @michielbdejong
    Angus: Which system is authoritative for which data?
    Are we designing a federated CRDT?
    We design the timesheets data model to be a CRDT
    Anybody who applies it directly gets the right answer
    But we know which author is authoritative for which part of the data
    like what we did for Collaborative Invoice Composition, the buyer can set the desired quantities, but the seller can set the unit price.
    Causal delivery
    Michiel de Jong
    @michielbdejong
    We express business rules, like 'the worker always enters their hours in m-ld', and 'the manager always enters their approval in prejournal'
    Then, we know that m-ld always wins for start & end time, and prejournal always wins for approval state.
    We could apply for some more funding to do the mathematics of this.
    With restrictions on who can do edits on which data, simplifying assumptions on the data structure, we can flatten the line of how complicated CRDTs get for complex data structures.
    Food for thought. :)
    It could also be a generic way to interface CRDT-based systems with classic CRUD systems
    Angus: it's setting the bounds of complexity before you need a full-blown CRDT
    --- end meeting notes ---
    Bob Haugen
    @bhaugen
    @michielbdejong
    I thought this might be interesting re Collaborative Invoice Composition:
    https://duckduckgo.com/?q=invoice+meaning
    Michiel de Jong
    @michielbdejong
    Thanks!
    Bob Haugen
    @bhaugen
    I mean, the various definitions of "invoice", who sends invoices to whom, etc.
    Eg if trading partners have agreed on commitments to transfer resources to each other reciprocally, they should not really need invoices.
    So Collaborative Invoice Composition could be more about the reciprocal agreements.
    Don't know if it is, though.
    Michiel de Jong
    @michielbdejong
    Interesting thought! Yes, it could be. Also just the process of buying things on an e-commerce website, you as the buyer add items to your cart, and the site as the seller fills in the unit prices, discounts, extras, and total.
    Bob Haugen
    @bhaugen
    We run into cases of collaborative {something} where trading partners negotiate sets of reciprocal resource transfers ending in agreements and then fulfillments of the reciprocal commitments.
    Bob Haugen
    @bhaugen
    Michiel de Jong
    @michielbdejong
    Nice!
    an “authenticated data structure” can have its operations independently verifiable. When resources in a network can attest to their own authenticity, then that data is inherently live – that is, canonical and transactable – no matter where it is located. This is a departure from the connection-centric model of the Web, where information is host-certified and therefore becomes dead when it is no longer hosted by its original service. Self-authenticating data moves authority to the user and therefore preserves the liveness of data across every hosting service.
    Michiel de Jong
    @michielbdejong

    https://www.cs.umd.edu/~mwh/papers/gpads.pdf

    An authenticated data structure (ADS) is a data structure whose
    operations can be carried out by an untrusted prover, the results of
    which a verifier can efficiently check as authentic. This is done
    by having the prover produce a compact proof that the verifier
    can check along with each operation’s result. ADSs thus support
    outsourcing data maintenance and processing tasks to untrusted
    servers without loss of integrity.

    Michiel de Jong
    @michielbdejong
    So I think that means data which you can deterministically reconstruct from a log of signed transactions (or signed messages). You would still need some trust chain to check the signatures against.