Today’s update:
Status
Its been a busy week, but I have some good news to share! Lets dig in:
New developer onboard!
Joining the Colony team is Maxx, a 10 year software engineer with an extensive JavaScript background. While my software development skills are akin to a toddler making macaroni art, Maxx is over here painting the Mona Lisa. His skills will be invaluable to making Colony not only functional, but a polished well tuned application
New development stack!
With 2 of us doing the work, we can divide and conquer. I spent much of the last month fighting Slint UI, drudging through type conversion hell. While it is OK, the JavaScript GUI world is leaps and bounds ahead. Based on a forum suggestion from loziniak, we dug into Tauri 2 which allows Maxx to focus on the frontend (which will be written using Svelte) and me to work solely on the Autonomi and crypto interactions in rust. Tauri 2 is fully cross platform, including for mobile, so one stack to rule them all. This is definitely the way to go.
But wait, isn’t this change going to slow things down? That’s what we’ve been working on this week!
Frontend Progress
Maxx basically rewrote the entire GUI demo that I had built in an afternoon and connected a couple buttons to some of my existing rust functions. So we’re up and running! No check-ins yet (still very messy), but we’re getting there.
Backend Progress
As for me, I’ve split out the core rust functions that I built in my demo, cleaned them up, and created a new repo on github called ColonyLib. As I’ve said in my pitches, I want to build up an Autonomi metadata standard. Colony is really just the vehicle to get us there. Colony will leverage ColonyLib to handle the master key creation, key derivation, pod creation, updates, and potentially RDF queries. This means any other Autonomi application can grab ColonyLib and know that whatever they write using their frontend application with be directly interoperable with Colony and its content discovery system.
Pods are being created!
Just this evening, I have successfully implemented a pointer/scratchpad combination in ColonyLib that I am calling a pod. The scratchpad is publicly readable (which is working!). The pointer points to the scratchpad and the counter field is updated for each update. The idea here is that when a user wants to refresh their pod cache (i.e. download all updates to pods) they just need to download the pointer, check if the count value is higher than their local cached copy, and then download the scratchpad vs downloading the scratchpad each time when often times, many of these will not change. The pointer can also be used to ‘hide’ data or move the pointer to something else. The concept here was for SOMA so that they could provide health information and when a user was done sharing that data with the provider, they could either point the pointer to itself or point it to some other data. Obviously, the provider could be caching that information, but I don’t think we can solve that in an ‘everything done client side’ world. Another problem for another day!
Thank you for your support!
Things are moving along nicely and we’re getting ready for the next phase. But we can’t do it without all of you! Thank you for all your support keeping Colony in the running. I am deeply honored. It makes the late nights and little sleep all worth it.
With your help, we can get this project finished and enable the world to Search Autonomi Simply!