By Colin Cantrell 

Hey everyone, sorry for the slight delay. I just needed a moment to finish up some tasks andw ait for a few more people to join. Thanks for being here, though!

So, I've been working on keeping up with the biweekly updates instead of doing them weekly. Weekly updates were a bit too tight, and I felt like I didn't have enough breathing space. Switching to biweekly should provide better consistency for all of you.
Recently, I've been making great progress. I've been working on the wiki, and Sohan has been doing an amazing job with it. The test net is up and running, along with the test net explorer. However, we encountered some security issues, and it seems like there were back doors and SSH keys that allowed unauthorized access. We're still investigating and securing everything, but we managed to bring everything back online.
This test net is essential for testing the staking and unstaking processes, and I didn't want to risk doing that on the main net. Luckily, we were able to recover from the setback, and the test net is now fully functional again. You can check it out at explorer.nexus.io.
The whole experience taught us a valuable lesson about decentralization. Critical infrastructure like this should never be in the hands of just one person. Going forward, we'll make sure to distribute responsibilities and keep things as decentralized as possible.
Anyway, despite the challenges, I can't really complain. We didn't lose much, just some time. Sohan and I have been working hard to pick up the pieces, and now Nexus 5.11 is almost ready for release. After my final tests, Kendall will do some testing, and we're planning to start public testing next week.
If any of you have experienced issues connecting to the core, we'd really appreciate your help with testing. This update, 5.11, involves a lot of work and touches on various aspects like staking transactions, stability, and efficiency. I must admit, I enjoy working on multiple things simultaneously. It keeps me engaged and energized!
So, I've been working on this exciting new architecture for the 5/2 feature build-out, and I think it's a step forward from the original reverse proxy and relay system. The idea is to create something akin to an onion routing system combined with a distributed hash table (DHT) and onion router.
Instead of connecting to a specific node with a fixed address, the new system will connect you to a node, and then when you want to establish a connection with someone else on the network, you'll connect to your closest nodes. These nodes will pass messages to find the route to the desired destination, making use of the DHT concept. This approach allows for scalability, even in networks with millions of nodes.
Once the route is established, you won't have to repeat the process every time you want to connect with that specific person. This creates a clear and direct pathway for future connections, which is pretty cool.
What I find particularly interesting about this architecture is its generic nature. Instead of focusing on specific protocol-level messaging, I'm developing it as a proxy. This means you'll be able to funnel any data over this system, and with elements of polymorphism in place, you should even be able to write your own protocol over the relay server protocol.
The potential benefits of this system are numerous. You can access anyone else's Genesis ID directly in a peer-to-peer fashion, even if they're behind a NAT and lack port forwarding. This anonymity is achieved by routing data through several hops, much like the onion routing system.
Security is a top priority, and the architecture incorporates multiple layers of encryption. Each hop in the relay process will have its own authentication and SSL using Khyber Post Quantum SSL, ensuring the data remains secure. Even if someone acts as an intermediary, they won't be able to eavesdrop on your communication due to the double-layer encryption.
In essence, the relay system is turning into an overlay, which aligns with Lisp terminology. And speaking of Lisp, I've been working on that too. Though there were some issues with the previous implementation in Python, I'm determined to address them and present a more robust and efficient solution for crypto EIDs with Lisps.
I'm planning to document and present all these ideas formally, maybe even as an RFC if anyone's interested in reviewing it. The future looks exciting, and I can't wait to see how this architecture evolves and revolutionizes the way we connect and communicate in the digital world.
Dina and I are considering collaborating on a project to write a C++ version of List. We have a decentralized mapping system, but we think we can develop something even better using pcap, which will make it really simple and incredibly fast. This ties in with our one stack too, making it all interconnected.
Now, let's talk about the relay system. By implementing an onion router functionality, we can achieve remote login capability. Essentially, you'll be able to forward an API request, creating a remote session on your local node, and then it gets forwarded through the onion routing system to the recipient's remote node that has access to the specific genesis. This is super beneficial for web-based apps, as it allows you to offload computation, making things more efficient.
The remote login also provides anonymity, as you're not binding your specific IP address to your genesis. So, people won't know if you're the originator of the chain or just one person in the chain. We're looking to scale this out even further to anonymize your actual tritium LLP IP, ensuring greater privacy.
And let's not forget the cryptographic identity aspect. Nexus allows us to bind a cryptographic key to a specific identity, solving the issue of identifying whether a key belongs to someone. Certificate authorities won't be necessary anymore, making the whole process more streamlined and less prone to corruption.
With this post-quantum SSL, you'll generate an encryption key through Kyber, which will have a consistent public key. Then you'll check this against the crypto object register to ensure it was deterministically generated for that specific user profile. A Falcon digital signature and timestamp will provide an extra layer of security to prevent replay attacks.
It's a pretty exciting project, and we believe it opens up new possibilities for anonymity and security in the world of decentralized systems. We're aiming to create a basic onion routing system over Nexus, and it's fantastic to see how this technology is evolving beyond what was previously available, like Tor Onion Router. Trust is essential, and Nexus is offering a more reliable solution in our eyes.
I've been working on this really exciting project that involves creating a powerful authentication system built over SSL, but without the need for certificate authorities. The best part is, it eliminates management attacks and threats posed by quantum computers breaking encryption or asymmetric cryptography like digital signature algorithms. It's a game-changer!
To make this system even better, I'm also developing a relay system with a distributed hash table and an onion-style setup. This will ensure that nodes remain anonymous and won't reveal their specific locations. Privacy and security are top priorities!
The main goal is to establish a peer-to-peer messenger and remote login using this protocol. This way, we can securely transmit encrypted information between parties without relying on centralized servers. I believe in decentralized messaging to avoid censorship and potential data retention issues.
As part of the project, I'm also considering developing a front-end messenger that allows real-time communication with peer-to-peer encrypted chat. Imagine sending a message through your mobile wallet before transferring coins – it's a seamless experience!
The onion rider design is pretty cool too. I plan to have two LLPs running over the relay server, transmitting raw binary data and checking specific address formats. By adding additional protocols on top of it, we can create various peer-to-peer communication systems and even anonymize specific data. This feature could also be handy for hosting files securely.
I'm aiming for a robust and versatile solution, so I don't like to limit myself. With this in mind, I'm also exploring the possibility of integrating VPN functionality. By using the onion routing relay system, we could run VPN traffic through it using the OpenVPN protocol. This way, we can ensure secure and private connections for users.
Overall, this project is evolving beautifully, and I'm thrilled to see it all come together. Necessity truly is the mother of all invention, and this challenge has sparked some fantastic ideas. I want to build something that's as capable and generic as possible right from the start.
I've been working on this relay system, and it's all about encapsulation and deencapsulation. It's like creating our own little onion routing on Nexus. The more nodes we have, the more complex the routes, and that means more traffic and better anonymization for transactions.
Initially, it's going to be used for a peer-to-peer messenger and remote login. But my ultimate goal is to run the tritium LLP through this relay system too. That way, I can create a lower level LLP and build all the tritium LLP on top of it. It's all about adding a layer of abstraction to achieve what I want.
The beauty of this system is that while it won't necessarily anonymize the transaction itself, it will hide the origins of the transaction. By jumping through different hops, nobody will know where a specific transaction originated from. This will be incredibly powerful for hosting web services. Imagine having services identifiable by a registered address rather than an IP address, and multiple nodes servicing it. It will truly anonymize your access to these services.
Now, let's talk about Mimble Wimble. It was a novel idea to take Bitcoin's UTXO to the next level, but it had some issues. A super node could easily break the anonymity, which isn't ideal for a decentralized network. But with our relay system and onion routing, we can protect against that. We'll limit the number of connections each node can form to maintain a distributed mesh.
I've been busy testing it out, and if you check out explorer.dot Nexus dot ao, you'll see the test net is up and running. There have been some hiccups with staking, but we're investigating and working on a final solution. Once that's sorted, it's pretty much a wrap for 511.
So, here's the super cool and exciting project we're working on: the People's Poll, a parallel voting system designed to bring blockchain technology into the realm of real-world issues. We're building an SMS-based voting app that will allow you to issue your vote or participate in polls with a simple text using short codes. And guess what? It's all going to be powered by the mighty Nexus blockchain, which is a seriously powerful tool!
The main goal is to create a secondary data set for voting, providing more evidence and transparency during elections. We want to ensure that there's no funny business going on, and this system will allow us to verify the accuracy of the results and detect any potential malfeasance.
What's even cooler is that this project aligns perfectly with our vision of making blockchain technology relatable and practical for everyone. We're tired of all the meme coins and speculative investments in the crypto world. Instead, we want to create an emotional connection with people by solving real-world problems.
Voting is just the beginning; we've got some other exciting use cases in the pipeline too. The app will have identity verification to ensure verified votes and maintain security. Plus, we're building strong relationships with people who are genuinely interested in what we're doing.
But wait, there's more! We're also getting the Bubble plugin back online after some unfortunate incidents. Our focus is on community involvement and decentralization. We believe that having an administrative branch voted in from the community can provide better oversight, conflict resolution, and support.
Our ultimate aim is to integrate Nexus seamlessly into people's lives and show them the value it brings. We're not just about financial gains; we want to make a real impact and improve things like agricultural supply chains.
I've been thinking about creating a community volunteer force or having people voted in to improve our liaison with the community and teams. It's all speculative at this point, but I believe it could be a positive step forward.
I'm planning to start holding regular sessions on Sundays at noon GMT -7 on the Constitution Channel. During these sessions, we can have open discussions and address any questions or concerns you may have. I want to be transparent and clear up any misunderstandings, so feel free to come and chat with me.
Speaking of the Constitution, I've been actively working on it and would love to get more community feedback. It's about 10 pages long now, and I'll share the link during our Sunday discussion.
Remember, this is a community-driven process, and I'm open to any suggestions or ideas you may have. If you feel my Constitution is lacking or you have better ideas, I encourage you to write your own version. We'll put all proposed constitutions to a vote and let the community decide.
On the hardware front, things are progressing well. I'm making great strides in various areas, including 3D printing parts, experimenting with different coil configurations, and working on clean energy systems. I'm quite optimistic about the progress so far.
I'll be available on Sunday in the Telegram channel for a text-based Ask Me Anything (AMA) session. It's an excellent opportunity to interact and ask questions, and I'm working on ways to make it even more interactive in the future. So don't hesitate to join in and share your thoughts.
Finally, I'm aiming to have a new beta version out early next week, and we'll also focus on getting the mobile wallet ready to go. Development can be a bit like those loading bars you see on computers, with progress sometimes slowing down before a big leap. But rest assured, I'm dedicated to making Nexus the best it can be.
I'm grateful for the positive vibes in the community, and I appreciate your ongoing support. See you all on Sunday at noon GMT -7 for our AMA and Constitution discussions. Let's keep making Nexus better together!
Thank you, everyone!