meshnet-lab
sucks
Our great sponsors
meshnet-lab | sucks | |
---|---|---|
2 | 3 | |
131 | 254 | |
- | - | |
8.3 | 10.0 | |
13 days ago | almost 4 years ago | |
Python | Python | |
MIT License | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
meshnet-lab
-
Meshtastic: An open source, off-grid, decentralized, mesh network
Most of the mobility testing has been performed either in the meshnet-lab[1] or the pineconesim[2].
As the original author of that documentation, it's quite entertaining to have it quoted back to me. :-) In any case the routing "prefers" links labelled as the internet when there is a tiebreak between two peerings between the same pair of nodes, i.e. you are connected to some other device via Wi-Fi and Bluetooth simultaneously.
And while it is true that Pinecone cannot necessarily always make the best routing decision based on public keys alone, aggressive queue management attempts to provide the best QoS for all flows and it scales very well because nodes maintain only a small amount of state about their position in the spanning tree and their position in the SNEK. Importantly, shortcuts can and often are taken when Pinecone switches to tree-based routing as the geometric distance to the destination on the tree is evaluated at each hop. Routing "by the SNEK" is used primarily to find the remote node and as a fallback in case the tree routing fails.
[1] https://github.com/mwarning/meshnet-lab
-
XMPP, a Comeback Story: A Protocol for Robust, Private and Decentralized Comms
Lots of interesting stuff there - thanks :) We're using https://github.com/mwarning/meshnet-lab rather than imunes.net for network simulation currently, but will take a look.
Power usage is looking pretty positive so far; as long as we route the Matrix traffic over the routing topology rather than going full-mesh it should minimise radio usage (the main battery suck, other than screen).
For store-and-forward, honestly using P2P Nodes as intermediaries is an okay approach other than exposing metadata to them. Our plan in the longer term is to switch to loopix-style mixnets to obfuscate the store and forwarding, a la nym.
In terms of joining the network by deriving a private key from a passphrase... yup, that could be cute, although slightly terrifying in terms of the risk of weak passphrases :)
We're hoping to get the P2P network stable in the coming year (although we were also aiming for this year originally :P)
sucks
-
Ladybird: A new cross-platform browser project
This is correct, and it's why most open-source software will never have much in the way of users:
> They're written from the perspective of the developers
And I get it. A few years back I had an open-source project [1] get users and it was terrible. What had previously been a fun technical exercise became a pain in the ass that felt a lot like actual work. I was relieved when my hardware broke and I had an excuse to archive the project.
But that does create a huge gap that mostly gets filled by commercial interests.
[1] https://github.com/wpietri/sucks
-
Professional maintainers: a wake-up call
It seems like you haven't quite got the concept of open source. If everybody consumes and nobody contributes, how long will that last?
A while back I bought a cheap robot vacuum. Their scheduling feature didn't meet my needs, so I reverse-engineered the protocol and open-sourced a cron-friendly CLI tool and a library so people could do other things with it: https://github.com/wpietri/sucks
Honestly, this was a mistake on my part. It was a demanding audience of home-automation hobbyists mostly without programming skills. The company was thoroughly unhelpful. When my vacuum finally broke, I was relieved, as I had a good excuse for trying to hand off the project. Nobody stepped up, so I shut it down. I just ran out of interest in doing free work to support a company worth billions.
I really admire the community spirit of open source But it's not sustainable if companies making their money off it keep depending on the niceness and generosity of others without giving back enough to keep them happy, healthy, productive people.
-
XMPP, a Comeback Story: A Protocol for Robust, Private and Decentralized Comms
I reverse-engineered the comms for my cheap Ecovacs robot vacuum and was surprised to discover that, like some angsty teen, it spent all day hanging out in an XMPP chatroom waiting for somebody to talk to it: https://github.com/wpietri/sucks/blob/master/developing.md
What are some alternatives?
cinny - Yet another matrix client
NomadNet - Communicate Freely
matrix-bifrost - General purpose bridging with a variety of backends including libpurple and xmpp.js
polyjuice_server
sh - Python process launching
Element - A glossy Matrix collaboration client for the web.
selling-partner-api - A PHP client library for Amazon's Selling Partner API
ocaml-matrix - Implementation of a matrix server in OCaml for MirageOS