meento

Four small tools that let a mesh vouch for itself.

Meento is the order and the reasoning behind four Meshare console utilities — Verify, Rank, Sync and Points. Run alone, each one answers a narrow question. Run in sequence, they answer a harder one: which servers, right now, are honestly holding the files this mesh actually agreed on — and who gets credit for keeping it that way.

1 Verify checks files against their hash 2 Rank finds the majority file list 3 Sync picks the winning ranking 4 Points rewards the servers that stayed
why this order

Each tool narrows what the next one is allowed to trust.

A mesh server starts out as just an entry in servers.txt — a URL, nothing more. Each stage in the pipeline earns that entry a little more standing, or removes it.

Verify goes first because nothing downstream should count a server that is caught serving a file whose content doesn't match its own <sha256>.<ext> name. It downloads every file it lists and removes any server with even one mismatch from servers.txt, before anyone tallies votes.

Rank goes second because, once the liars are gone, the question changes from "is this server honest" to "what does this honest group actually agree it's holding." It turns each server's raw files.txt into one list: the files present in more than half of the servers that answered.

Sync goes third because different servers publish their own rank.txt at different moments, and they won't all agree. Sync fetches every server's published ranking, groups the identical ones, and scores each group by distinct IPs × list length — so a handful of servers on the same machine can't out-vote a smaller but more diverse group. The winning group becomes sync_servers.txt: the mesh's current, adopted membership.

Points goes last because it's the only stage that needs a settled membership to mean anything. It reads sync_servers.txt and layers a signed accrual-and-transfer ledger on top — a day of membership earns a point, and points can be sent between servers. It's the optional part: a mesh is fully functional after Sync alone.

the four tools

What each one reads, writes, and is for.

1

MeshareVerify servers.txt → servers.txt

Downloads every file a server claims to hold and re-hashes it while streaming, nothing touches disk. One mismatch is enough to remove that server from servers.txt. A server that's merely offline, or that 404s on a file it listed, can't be proven corrupted — it stays, marked "not fully verified."
readsservers.txt, each server's files.txt and /files/*
writesservers.txt (in place), servers_log.txt (appended history)
gives youa membership list you can prove nobody has caught lying about a file's content
2

MeshareRank servers.txt → rank.txt

Reads every server's files.txt and keeps the files that appear in a majority of the servers that could be reached — an offline server doesn't count against anything, it simply doesn't vote. Ties are broken alphabetically. The result is one ranked list, most widespread file first.
readseach server's files.txt
writesrank.txt (overwritten each run)
gives youone server's honest opinion of what the mesh, as a whole, actually holds
3

MeshareSync servers.txt → sync_servers.txt

Fetches rank.txt from every server, groups the ones that are byte-for-byte the same ranking, and scores each group by distinct IP addresses in it, multiplied by how many entries the ranking holds. Highest score wins, even if it's a minority of servers — the console prints the exact tally so you can see why.
readseach server's published rank.txt
writessync_servers.txt (written to a temp file, then moved)
gives youthe one ranking the mesh currently agrees to run on, and who's in that agreement
4

MesharePoints sync_servers.txt → points_ledger.txt

Treats sync_servers.txt as the roster: every member earns a point per day it's on it. Transfers are signed with an RSA key and broadcast by HTTP GET to the whole mesh; every receiver checks the signature before recording anything.
readssync_servers.txt
writespoints_ledger.txt, transactions.txt, its own keypair
gives youa lightweight, optional reason for servers to keep showing up honestly
trust model

None of this is Byzantine fault tolerant, and it isn't trying to be.

Verify proves file content. Rank and Sync are majority and IP-weighted votes, not cryptographic consensus — a server can still publish a self-serving rank.txt, it just won't win unless enough of the mesh happens to agree with it. Points is weaker still: signatures stop anyone from forging a transfer "from" a server they don't control, but they don't stop a dishonest member from broadcasting a false balance for itself.

Use it the way you already trust the mesh.

Every stage assumes you already trust the servers roughly as much as you trust them to publish an honest rank.txt in the first place. If a machine in your mesh is actually hostile, none of these four tools stop it from voting, signing, and reporting balances consistently — they only stop it from forging messages as someone else.

building on meento

What the pipeline leaves open on purpose.

Each tool writes plain text files and nothing more, which is exactly what makes them easy to build on top of.

  • A mesh-health dashboard Read rank.txt, sync_servers.txt and points_ledger.txt across the whole mesh and render who's in, who fell out at the last Sync, and whose balance is climbing.
  • Reputation-weighted voting Feed each server's Points balance back into Rank or Sync as a weight, so a server with a long honest history counts for more than a fresh IP that showed up yesterday.
  • A bootstrap / discovery service Seed a brand-new node's servers.txt from an already-trusted node's sync_servers.txt, instead of hand-typing peer URLs.
  • One wrapper, four cron jobs Every tool already runs non-interactively (--accrual-only, or no flags at all for Verify/Rank/ Sync). A single systemd timer chain — Verify, then Rank, then Sync, then Points — turns the pipeline into unattended infrastructure.
  • Federated meshes Run separate Verify/Rank/Sync groups per content category, and only merge the servers that appear in every category's sync_servers.txt.
  • Automated reconciliation MesharePoints' "pull a peer's ledger" option is a manual diagnostic today. Scheduled, it becomes a way to catch a diverging balance before it's acted on.
suggestions

Where each tool could grow next.

None of these are required to use the pipeline today — they're the places the current design leaves an obvious next step.

MeshareVerify servers.txt → servers.txt

  • Check servers in parallel rather than one at a time — large meshes currently take a while because every listed file is downloaded in full, sequentially.
  • Cache which files already verified clean on a given server, so a re-run only re-checks what's new since last time.
  • Make the 10 s / 30 s timeouts a command-line flag instead of a fixed value, for meshes on slower links.
  • Give removed servers a path back in — right now nothing re-adds a server once it's fixed, short of hand-editing servers.txt.
  • Sign each run's block in servers_log.txt, so the report itself can be trusted second-hand.

MeshareRank servers.txt → rank.txt

  • Make the majority threshold configurable — some meshes may want a stricter bar than "more than half."
  • Let a server's vote be weighted by its MesharePoints balance or verification history, instead of every reachable server counting equally.
  • Keep prior versions of rank.txt instead of overwriting, so a sudden drop in agreed files is visible as a diff, not silent.
  • Fetch every server's files.txt in parallel — currently the biggest cost as the mesh grows.
  • Break ties by something other than alphabetical order, e.g. file freshness, when that data is available.

MeshareSync servers.txt → sync_servers.txt

  • Warn when the winning group flips between consecutive runs — a flapping winner is worth surfacing, not just silently overwriting sync_servers.txt.
  • Weight the score by verification or reputation standing, not just raw entry count — today a long rank.txt from an unverified group can outscore a short one from a well-verified group.
  • Cache IP resolution across runs so a server can't game the "distinct IPs" count by shifting DNS between runs.
  • Treat IPv6 and IPv4 addresses for the same host as one server when both resolve to it, rather than as two.
  • Offer a configurable tie-break beyond "earlier in servers.txt," such as longest uptime in prior syncs.

MesharePoints sync_servers.txt → points_ledger.txt

  • Add sequence numbers or nonces to signed transfers, so an old, validly-signed broadcast can't be replayed later.
  • Serve the broadcast endpoints over HTTPS with peer authentication — they're plain HTTP GET today, same as the rest of Meshare.
  • Add a supply or balance-sanity check, since the cooperative-trust model means nothing stops a member from reporting an inflated balance for itself.
  • Rate-limit accrual and transfer broadcasts per key, so a compromised private key can't flood the mesh.
  • Automate menu option 6 (pull a peer's ledger) into a scheduled reconciliation, instead of a manual diagnostic.