What is Oxen?
Why buy $OXEN?
How do I stake $OXEN?
Who uses Oxen?
What can be built?
Session & Lokinet
Get involved
Roadmap
FAQ
Weekly Dev Update #86

Weekly Dev Update #86

04 February 2020Admin

Hey Y’all, 

Last week was a mad dash to get final parts of Session in place for the upcoming release this week. We also continued working on Lokinet 0.7.0 changes and and started building out the parts necessary for some incremental post-launch updates to Session.

Loki Core

Lokinet

If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at https://www.twitch.tv/uguu25519. He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What went on last week with Lokinet:

We spent the week focused on the three pieces we want in a 0.7.0 release: gossip router announcements, RC lookup fixes, and DHT blinding. It is worth explaining these components in some detail:

Gossip announcements change the way routers send their Router Contact (RC) info to other routers. Previously, routers would broadcast a random set of the RCs they know about to the routers they have direct connections to. This didn’t scale well, so we worked on replacing it with a model based on the how lokid sends uptime proofs: each router broadcasts its RC to all connected routers once per hour.

RC lookups — needed when a client wants to build a path — were also broken on the larger network because not enough nodes were being considered when messages propagated across the DHT.  We fixed this so that DHT lookups now consider all nodes (which required the gossip protocol change), which should make path builds both faster and considerably more reliable.

DHT blinding lets clients hide a .loki address when telling the network how to reach it.  Instead of publishing a record that says “reach xyz123.loki through this router”, it now publishes the same data, but encrypted using the .loki address as a password, and using a derived public key to send the client contact record (the “introset”) to the network.

For example, supposing the derived public key for “xyz123” is “abc789”: anyone who wants to look up xyz123.loki will now lookup abc789 instead, get the encrypted data, then use “xyz123” to decrypt it and find the contact information. (This derived key also has a derived private key which is used to sign the record so that someone else can’t forge the “abc789” record).  The end result: clients can provide their contact info, other clients can access that info, but no-one who doesn’t already know the .loki address can discover it from the data on the network. Thus, your .loki address stays completely hidden to everyone except those who you give it to.

PR Activity:

Loki Messenger 

Loki Messenger iOS

Loki Messenger Android

Loki Messenger Desktop 

Loki MQ

Loki MQ will be used as a dedicated communications layer for inter-snode communications to help more efficiently extend Service Node proxying

Thanks,

Kee 

You've got mail!

Sign up to our newsletter to keep up to date with everything Oxen.