P2P Discussion

[RocksteadyTC]

[5:18 PM]

karai-link: RockSteady (TRTL): what if i spin my own p2p to handle peer routing and then later replace it with libp2p when i fully grok what our implementation would need? currently, we're generating several identities when we could be using native TRTL crypto to not only manage funds but manage identity and signing etc.
might not even need libp2p. its cool that it gives us things like ip6 and quic and better NAT routing but damn its really a blocking point for me right now where i could just as easily implement one of several p2p schemes ive been cooking up
[5:19 PM] turtle.army: what factors are causing it to be a blocking point
[5:19 PM] turtle.army: if you think it makes sense to roll your own p2p then I'd say go for it
[5:20 PM]

karai-link: RockSteady (TRTL): the breadth of all the modules available in libp2p leave me open to implementing something that would technically function but leave open risks and inefficiencies in the final product
[5:21 PM]

karai-link: RockSteady (TRTL): like for example im currently generating a peer identity, and using native TRTL crypto and then also using wallet-api
[5:21 PM] turtle.army: that makes sense
[5:21 PM]

karai-link: RockSteady (TRTL): all of that has a cost, and a code/knowledge burden
[5:22 PM]

karai-link: RockSteady (TRTL): i like being the only guy making this, and its a simple app so im just chopping wood at this point. knowing the p2p stack and being able to take those concepts and craft a bespoke solution i think would be better in the short term and possibly the long run
[5:22 PM]

karai-link: RockSteady (TRTL): i dont want perfection to be the enemy of good, right now
[5:27 PM] turtle.army: as long as you make everything modular i guess it's no problem if you decide to do something else later on
[5:34 PM]

karai-link: RockSteady (TRTL): im not sure how modular the p2p stack would be but i like things to be as decoupled as possible. I'm thinking a low latency QUIC based interaction using this library here: https://github.com/lucas-clemente/quic-go
[5:40 PM]

karai-link: RockSteady (TRTL): im thinking it works like this..

• client joins channel for the first time,
• peer identity is recognized as new by coordinator,
• peer+coordinator handshake occurs
• coordinator assigns a unique ID to the peer combining their pubkey + coordinator pubkey + KDX ID + salt (maybe)
• that peer is then added to a kv peerlist with hashedpeer ID plus connection info
• Im debatin whether or not peers need to speak to eachother, it would help but it would also mean we need more safeguards against bad peers
• from there, peers relay TX's to the coordinator
• coordinator validates and triages the TX
• coordinators appends TX to graph
  [5:41 PM] turtle.army: what is the peer communication going to look like
  [5:41 PM] turtle.army: hex like the daemon?
  [5:41 PM]

karai-link: RockSteady (TRTL): when you say peer communication what do you mean
[5:42 PM] turtle.army: messages that the peers send to eachother
[5:42 PM] turtle.army: whatever that happens to be
[5:42 PM]

karai-link: RockSteady (TRTL): > - Im debatin whether or not peers need to speak to eachother, it would help but it would also mean we need more safeguards against bad peers
[5:42 PM]

karai-link: RockSteady (TRTL): i hadn't considered that part yet
[5:42 PM] turtle.army: so for now the communication is only with the coordinator
[5:42 PM]

karai-link: RockSteady (TRTL): do you hav any suggestions
[5:44 PM]

karai-link: RockSteady (TRTL): I think for now, it would probably resemble that, but I'd like for the peer-peer interaction to be intelligent rather than for filling latency gaps or for dictating non-existent-consensus
[5:44 PM]

karai-link: RockSteady (TRTL): to answer you more directly, im not sure of how the data will look as it floats over the wire
[5:46 PM] turtle.army: i guess it sort of depends on what use case we're trying to get out of the channel, but certainly i can see a desire for direct peer to peer communication
[5:47 PM]

karai-link: RockSteady (TRTL): yeah probably should stick a pin in that one and revisit it
[5:47 PM]

karai-link: RockSteady (TRTL): i am thinking about what types of stuff the coord will have to maintain in its knowledge of peers
[5:48 PM]

karai-link: RockSteady (TRTL): im guessing i could do a list of peers we know of who are online, then a list of peers we know of who are not online, then a list of peers we dont want to communicate with
[5:49 PM]

karai-link: RockSteady (TRTL): what are my other options besides hex for moving data over the wire
[6:52 PM] zpalmtree: json, xml, protobufs, custom formats, whatever the heck you like, it's just bytes
[6:52 PM]

karai-link: RockSteady (TRTL): i think i work better by describing how things should work and then going and building it... lemme just spitball some ideas in detail about how this would work from start to finish just for my own benefit...
[6:53 PM]

karai-link: RockSteady (TRTL): oh hi z
[6:53 PM] zpalmtree: hi
[6:53 PM]

karai-link: RockSteady (TRTL): were you about to say something
[6:53 PM] zpalmtree: what i just said? lol
[6:54 PM]

karai-link: RockSteady (TRTL): any favorite? currently everything is json so i figured id just use that but eggdre proposed hex and i guess i just hadn't thought of it at that point yet
[6:54 PM]

karai-link: RockSteady (TRTL): interested in your opinions, pros cons etc
[6:55 PM] zpalmtree: i think starting with JSON is a good idea, every single language has a library for it, it's human readable, it's easy to use. If you later on decide you need smaller payloads or you want stream deserializing or whatever, then you can implement something more efficient at that point
[6:55 PM]

karai-link: RockSteady (TRTL): ok sounds like a good plan
[6:55 PM]

karai-link: RockSteady (TRTL): thanks for contributing your opinion
[7:13 PM] SoreGums: also if go with json now something else later - then clients that want to go the optimal route can while still supporting all the other clients as all the others still can use json 😉
[7:14 PM]

karai-link: RockSteady (TRTL): alrighty so picking up where i left off.. I think it should work this way, assuming that user is an app or human but im just going to say user because i keep calling it that for some reason.

• user finds ktx address..
• user uses connect-channel format in karai client
  [7:15 PM]

karai-link: RockSteady (TRTL): - user's karai instance sends a version query to the channel coordinator first. (the logic behind this is if we can't talk anyway, we should end the convo as soon as possible)

• version query fails to satisfy version required, disconnect, record ktx address and version info
• version query passes, the user sends their own version /client header to initiate handshake process
• if any authentication of a user in a private channel is required this is where someone would implement that.
• the coordinator responds to the handshake request with the most current milestone tx transaction defining the governance parameters of the channel
• user responds with ACK as a standard transaction in the channel announcing the completion of the handshake process
• assuming the ACK is accepted, the coordinator broadcasts the join TX and the process is done.
  [7:40 PM]

karai-link: RockSteady (TRTL): @iburnmycd I noticed you typing
[7:44 PM] iburnmycd: nah, mobile keyboard hover as i was scanning through. good so far from what i can tell.
[7:44 PM]

karai-link: RockSteady (TRTL): ok cool.
[7:45 PM] iburnmycd: the only consideration I may have, is in response to soregum's comment -- is that in maintaining unoptimized communication protocols and optimized communication protocols side by side, you have to consider the bandwidth and load factors of the serialization/deserialization, transmit & ACK side of things, etc.
[7:46 PM] iburnmycd: It may be... inconsequential... depending on the payloads themselves... but it's something to consider nonetheless
[7:47 PM]

karai-link: RockSteady (TRTL): building on the issue of peer-to-coord vs peer-to-peer, i think it could be possible for the user to define whether they want to be part of a swarm or have purely peer-to-coordinator traffic for the purposes of privacy. if you want to help out by relaying messages, you should be allowed to do that, and it would be simple for the coord to assign a truth score via how often that peer relays an erroneous hash
[7:47 PM] iburnmycd: kind of like the discussion about the pointer addresses -- it doesn't seem like much to shave off the 10 bytes (or whatever it was), but over a long enough period and enough chatter, 10 bytes blooms fast
[7:48 PM] iburnmycd: if you've got a coordinator in the middle.... why maintain a "truth score" when there are other established ways to handle that
[7:48 PM]

karai-link: RockSteady (TRTL): yeah every bit adds up
[7:48 PM]

karai-link: RockSteady (TRTL): can you elaborate on one
[7:48 PM] iburnmycd: why couldn't a coordinator sign a cert, that the user/node uses to relay -- then the coord can revoke the cert via the equiv of a CRL
[7:48 PM] iburnmycd: basically, establish a PKI for the channel
[7:49 PM]

karai-link: RockSteady (TRTL): in the peer-to-coordinator model there is no need for a truth score, i should add
[7:49 PM] iburnmycd: agreed, i was talking about:

if you want to help out by relaying messages, you should be allowed to do that, and it would be simple for the coord to assign a truth score via how often that peer relays an erroneous hash
[7:49 PM]

karai-link: RockSteady (TRTL): that would be cool to do.
[7:50 PM] iburnmycd: on join of swarm, node creates a CSR, sends CSR to coordinator, who signs it, sends back the cert, node uses the CRT for presentation to others for relaying, etc.
[7:51 PM]

karai-link: RockSteady (TRTL): that's doable.
[7:51 PM] iburnmycd: only the coord would be permitted, in the protocol, to have a self-signed cert (or, one of the attributes, like the CA bits set)
[7:51 PM]

karai-link: RockSteady (TRTL): i might need some direction as far as how to set this up, but i think i can get away with building it out sans pki and then adding pki to the handshake process in a protocol upgrade once the mvp is up
[7:51 PM] iburnmycd: other nodes would always look to the coord, that publishes the CRL to determine if someone is untrusted, and revoke the cert, etc etc etc
[7:52 PM] iburnmycd: aye
[7:52 PM] iburnmycd: hell, you could even distribute the CRL and it's updates in a chain kind of way, but the CRL and the updates are always signed by the coord :slight_smile:
[7:52 PM]

karai-link: RockSteady (TRTL): yeah i like where you're going with that. it kinda pertains to what i was talking about earlier with regard to minimizing new keys and such. is there any potential to use TRTL crypto for our cert keys?
[7:53 PM] iburnmycd: and it wouldn't have to be a "normal" PKI, you could use the existing keys, publish the list, sign it, etc using the standard ed25519 stuff
[7:53 PM]

karai-link: RockSteady (TRTL): ok
[7:53 PM] iburnmycd: aye-- TRTL crypto keys are good for signing 100% -- encryption, requires translation to X25519 or some other form
[7:55 PM]

karai-link: RockSteady (TRTL): alrighty
[7:55 PM] iburnmycd: point being, it could be a simple check -- something as simple as, node presents it's public key to the coord, coord signs the public key with it's private key, sends back the signature, node presents it's public key & signature to all downstream nodes, they check that signature against the known coord public key, verify the authenticity -- and you're good.

coord publishes a list of revoked signatures that it signs and pushes out on the network as required.
[7:56 PM] iburnmycd: if a downstream node receives a public key, and signature, that's on the published revocation list, no bingo, move on, NEXT
[7:56 PM]

karai-link: RockSteady (TRTL): those can be published in the milestone tx
[7:56 PM] iburnmycd: perfect place
[7:56 PM]

karai-link: RockSteady (TRTL): yep, its made for governance type stuff and its one of the tx's that must be scanned
[7:57 PM] iburnmycd: just an idea -- didn't let it simmer or bake much -- it's still a loose ball of dough that hasn't risen yet --- everywhere is out of yeast 😦