• It's not linear it's compact

    Hsingai Tigris Altaica • 04/01/2026 at 04:08 • 0 comments

    n is the max number of nodes.

    p is the number of address stored per entry.

    d is the overhead of a level

    p=1 it just stores 1 address of a node managing the block and d = 0 then for 64 address space that is 16k bytes

    this a O(log(n)^2) memory per node

    use the 128 bit address space of ip6  just 4 mebibytes is enough to store a 128 path for each entry that means it would only need a average branching factor of 2

  • Break thru in the Distributed Dictionary

    Hsingai Tigris Altaica • 03/31/2026 at 06:23 • 0 comments



    I'm been work on a system where the address space is broken into 256 blocks then each of those block is broken into 256 blocks until to get a block of 256 addresses.

    this means a node only needs to keep track of 

    routing blocks. where n is the size of the address space.
    The -1 is because the highest block don't contain blocks but the address directly and those are kept tracked of only in the direct routing table.

    For a 64 bit address that's 1792 entries.
    So a node only tracks 1792 blocks in its volume of the dictionary and (1793 * number_of_experts) + 255 nodes in its routing table.

    That's O(1) memory usage and if a node has more memory, it can take advantage of to keep track of more blocks and increase the performance.

    I just realize today that that at each level only a max of N blocks will contain any nodes. where N is the number of nodes on the network. and since each node keeps track of one block for each level.

    So there will always be enough capacity to store the complete routing information for the entire network even is every node is only doing the minimum 

    This also means that node can just keep track of the blocks that it's own address is in. at each level.

    I'm still working on how to handle the routing tables. The fact that node might not have an entry for an address means most algos won't work.

  • Distributed dictinarys

    Hsingai Tigris Altaica • 11/11/2025 at 09:36 • 0 comments

    I discovered distributed dictionaries and had the idea of using multiple levels.

    the bottom level keeps track of 256 first level nodes, each of which keeps track of 256 nodes which on the second level keep track of 256 nodes which on the third level keep track of  nodes... and so on.

    you only need 8 levels and the system can keep track of 2^64 nodes and each node only keeps track of 256*8 nodes 

    thou for message efferently reason I use 128 nodes in each layer above the first so nodes need to keep track of a minimum of 256 + (128*8) nodes

    when looking up a node or forwards it to the node with cover that range of the target's address at the highest level.

    This allows the system to take advantage of nodes with greater memory as it can keep track of more node and so it routs in fewer hops.

    I'm still working on the latter networking, where nodes keep track of other nodes that are covering the same region of a level

  • How to tell if your rebroadcast would be beneficial

    Hsingai Tigris Altaica • 07/19/2025 at 10:02 • 0 comments

    Meshtastic uses RSSI to determine who should rebroadcast a message.

    it does this by making the node wait longer the stronger the receives singles strength is. then not rebroadcast if you heard someone else rebroadcast it before you.

    IF you assume that RSSI is a measure of distance, then what you want is to not rebroadcast if you hear a rebroadcast with a stronger signal.

    If it's weaker than the rebroadcast is on the opposite side of origin that you, so your coverage doesn't overlap with the rebroadcast that much.

    The other possibilities are:
    • That it was rebroadcast by a weak transmitter which case is didn't reach many nodes. In which case ether you are weak transmitter and won't reach many nodes either so your rebroadcasting won't have much effect; or you are better transmitter and will cover a broader area than the rebroadcast you hear.
    • That you are in the middle between the origin and the reboardcaster; so one should probably put a minimum received signal strength for using this rule to decide to rebroadcast. Thou ideals if they are both close by it wouldn't have rebroadcasted

  • detecting looping is routing information

    Hsingai Tigris Altaica • 06/23/2025 at 04:42 • 0 comments

    Here’s a little something on networking, when the routing table changes it’s only because of a change in the topology of the network.

    So if you send the id of the link that changed you can detect loops if a node gets the same update twice.

    at a minimum if you only want the node that formed the loop to detect it then it can look if the node it’s routing says, “Hay I got a new distance to destination by going thou your link to me“

    but to enable any node to detect loops to need more information than just the link ID as the link might change more than once. But that’s pretty much just Sequence Number from Destination-Sequenced Distance-Vector.

    I still have to analyze this more to see if there is race condition in situations like:

    An … A2, A1, destination, B1, B2 … Bn

    then b1 changes it route to destination to go thru An and A1 changes it route to destination to go thru Bn before the other’s route update reaches them

  • Static routing and the edge

    Hsingai Tigris Altaica • 05/09/2025 at 06:27 • 0 comments

    Say you have 3 nodes A and C are in range of B but not each other.  C is a static node and A and B are mobile nodes

    if A sends a message B can no it needs to rebroadcast becomes he doesn't hear C broadcast it.

    but how can B know he needs to rebroadcast a message from C so that A can hear it?

    Borrowing from Meshtatstic. If a mobile node doesn't hear a message from a at least two nodes and at least one of them is a mobile node it should rebroadcast it.

    This still has the issue of  what if A isn't in range of mobile node D that B heard rebroadcast the message. but Meshtastic has the same issue so I think we can call it good enough for now.
    might add some 'micro routing' for mobile nodes that instead keep routing to the whole network just to a static node. kinda like your star networking only the root isn't a single node but the whole static routing network.

  • Finaly getting hardware and learned morea bout BLuetooth and andriod

    Hsingai Tigris Altaica • 10/26/2024 at 09:16 • 2 comments

    I got a T-deck for my PDA project and decided to get one with LoRa because, why not. Then I got a Heltec Lora32 v3 and Cardputer for Xmas last year.  

    I'm been busy trying to start my game studio so haven't had much time to work on it but the 2 years I'd given to starting it are finally up. 

    This year I'm getting a few of Circuit Digest's LiteWing drone to experiment with autonomous repositioning to improve the new work coverage and data ferrying.

    I found out just how slow LoRa is and how small the MTU is.  I know the numbers, but I don't realize the practical significance of them

    We attached a finder to the remote we keep losing, it wasn't a bluebooth one but it got me interest in those Bluetooth beacons like the Airtags.

    So I learned some about Bluetooth to find out if you could make your own app for them.

    So looking into it, It shouldn't be that hard to make scatternet out of Bluetooth/WiFi the device would operate as WiFi AP/Bluetooth Peripheral and when a node wants to send data to it, it connects.

    This means it would be point to point and not broadcast like I wanted but with the higher data rates it should be a problem.  

    I'm not sure about how Ergonomic it'd be. I think on android the user just needs to accept the connection once then it will allow it to connect to the device again. but I'm not sure.  

    Even it is a PITA, it would still allow you to connect to the network with an ordinary phone.

    and it should be work perfectly on Linux computers and nRF52, ESP32s.

    on the protocol front I was thinking of the network make a Minimum Spanning Tree to give nodes a topological coordinate but then I heard about Minimum Diameter Spanning Trees and realized that what I really wanted. 

    We can use the Spanning Tree to reach any node from any node, now I'm looking into ways to find better paths between nodes

    Right now, I'm thinking about each node keeping track of all the nodes that it can reach by 2 disjoined paths

    I'm also considering some sort of hierarchical clustering-based routing.

  • some thoughts on routing

    Hsingai Tigris Altaica • 09/03/2023 at 13:45 • 0 comments

    I never got a Lora or EPS32 board to develop on but I want to get one of the the new T-Decks to program as a PDA to remind me to take my meds and it has a LoRa module. So I'm looking into Wakan again. tough I don't has a much free time as I use to.

    Anyways Wakan nodes don't keep track of how to route messages TO other nodes. they keep track of how to route messages FROM other nodes to them. I'm calling them 'etuor' ('route' backwards)

    lets call the nodes in the nodes in a nodes's Etuoring table it's acquaintance nodes.

    When a node(A) receive a message from node(B) going to a destination(C) it will find the node(D) on the message's route closest to the destination(C) that it knows about then remove itself(A) and all nodes farther from destination(C) from the messages route then do it's check if it should rebroadcast the message going from B for D and if so broadcast it.

    the other thing I was thinking of was:

    when trying to find a node that isn't in it's etuoring table it should find the closes and farthest(in the kadmilla sense) and send messages to them asking if they know,

    This is based on the 6 degrees of separation and the reason the farthest and closest is to avoid local minima

    and if they don't know they do the same. 

    This leap frogs the routeing list as the intermediate nodes aren't add just the ones ones. 

    of course if it doesn't know it just add the node it was asked to look up to it's list of nodes it's trying to find, and if it is already trying to find it just as the asking to the list one node it should notify when it finds out.


    of course this all assumes that nodes can store messages for much long than the time it takes for the update to happen.

    lets call the your acquaintance node that is farthest from you your far node. 

    Let's  call the your acquaintance node that is farthest from your far node your counter node.

    maybe we could do something with building paths from your far node's far node's far node's....

    of course you don't really want your far node of your far node you want the acquaintance from of your far node that is farthest from you.

    maybe something keep track of the nodes you know of that are farthest apart from each other, lets call them 'The Ends of The World'

    There is  an Upper End of the World which is The End of The World with the highest id and a 'Lower End of the World'

     with the lowest id.

    Let your 'Upper frontier' be your acquaintance node that is closest to the Upper End of The World.

    Like wise with your 'Lower frontier'

    maybe keep track of your Upper Frontier's Upper Frontier's... and like wise with your Lower Frontier


     these should be agreed upon globally, so if you can track of route to them it should be light on transmission over head for the network and of worst the  diameter of the network in storage.

    do to the triangle inequality the new end should be close to the old end

    The rate of the heartbeats The Ends of the World send out should be able to be quite slow as they are just used to optimize routing not a vital part of it.

    if a end dies then you try  to form a connection to the know you think is farthest. any node in the path can respond with a node it knows is farther. and the news of the know death is going to travel from the nodes netographically closest to the dead End of the World so it should find the new end then flood that information to the network before to many inquires about who the new End of The World is get sent.

  • Why it's called 'Wakan'

    Hsingai Tigris Altaica • 04/05/2022 at 01:47 • 0 comments

    I found the original Logo on a old harddrive. I has one of the Chinese characters wrong.

    Wakan comes from the etymology of the word 'Japan' one theory is that it comes from 和寛 which in the dialect of the time/place sounded like Wakan.  

    和寛 in turns comes from the ferries used to reach Japan.

    I liked the imagery of your  the underlay networks being islands and the overlay network as ferries taking  the data between them.

    I don't have Photoshop installed and when Krita it din't come thru as text layers.. I don't know if the text was prerendered in the PSD. so I recreated it in Krita

  • Who needs sleep?

    Hsingai Tigris Altaica • 04/04/2022 at 14:39 • 0 comments 

    func passthruKa(R, A, B){
    if (I know of a shorter route from A to B than the route that passes thru R){
        return(False)
    else {
        return(True)
    }
}

     The difference between passthruKa and RelayKa is that if you don't know of any routes from A to B RelayKa will return True while passthruKa will return False.

    when tracing route the stations will broadcast the Trace messages if they  passthruKa them.

    when (station_A hears a ChartRoute message from station_B) then {
    if (ChartRoute isn't in station_A["recent_message_list"]) then {
       if RelayKa(station_A, station_B, Chart_Route["GOAL"]) then {
            if (ChartRoute["PATH"] is empty) then {
                broadcast Trace(PATH : [station_B])
            } else {
                broadcast Trace(PATH: [...ChartRoute["PATH"], station_B])
            }
            append station_B to the end of ChartRoute["PATH"]
            broadcast the modified ChartRoute
        }
    }
}
    when(station_A hears a Trace from station_B) then {
    if (Trace isn't in station_A["recent_message_list"]) then {
        if passthruKa(station_A, station_B, Trace["PATH"][]) then {
            rebroadcast Trace
        }
    }
}
    when (station_A hears a PingRoute message from station_B) then {
    if (station_A == PingRoute["ROUTE"][0]) then {
        add Ack(ORIGIN: station_B, FOUNT: PingRoute["ROUTE"][0]) to station_A["recent_message_list"]
        pop PingRoute["ROUTE"][0]
        broadcast modified PingRoute 
    } else if (station_A != PingRoute["ROUTE"][0]) then {
        broadcast Ack(ORIGIN: station_B, FOUNT: PingRoute["ORIGIN"])
}
    when(station_A hears a Ack from station_B) then {
    if (Ack isn't in station_A["recent_message_list"]) then {
        if passthruKa(station_A, station_B, Ack["FOUNT"]) then {
            rebroadcast Ack
        }
    }
}