• The problem
  • Did you know...
• The Mission in xx Network era 1107
• Rewards
  • Rewards for participating validators
  • Rewards for Space chat participants (non-validators welcome!)
• Rules
  • Rules and crieteria for participating validators
    • Criteria for validators
  • Rules for non-validating chat participants
• Payouts
• Technical tips
  • How to find IP address for the validator?
  • How to block and unblock an IP address?
  • How to sign your wallet address?
  • What happens to my validator if I participate?
• Questions and answers about the game
  • What happens if the target changes their IP address?
  • How can I time the firewall rule to begin or end just before or after the era?
  • How does the nominator compensation work?
  • What is the expected outcome
  • Is denying IPv4 access the best way
• Sample game workflow for validators
• Hop on the chat to get started

The problem​

xx Network has a small, but growing number of nodes owned by centralized entities ("pools"). As far as I can tell most Substrate-based chains do.

I happen to care about xx Network and I don't think we should have anyone control more nodes than the current cMixx round size (which is five).

There are variuos measures the xx Network Council has initiated to protect enhance decentralization, but as a demonstration of a working decentralized approach I'm willing to spend some of my XX coins to make a point.

Did you know...​

This is only loosely related, but: did you know that Polkadot has a community event called "The Spammering" that is about to happen?

The Spammening, Polkadot’s ultimate stress test!

Polkadot is about to be put to the test as we push it to its limits in real-time. Get ready to witness the network’s resilience and scalability under extreme load as we #RekTheMeter!

This game can be thought of as a watered-down version of xx Network spammering (and in the opposite direction).

The Mission in xx Network era 1107​

Your mission is to block an IPv4 address of a cMix ID node (the cMix ID) during the game era ("the era", which is 1107).

That IPv4 address will belong to a pool node identified by the cMix ID.

The cMix ID will be shared 3-4 hours before the era begins so that you have time to find and block the IP (which takes mere seconds - see below).

Rewards​

Rewards for participating validators​

You will get over 100% of your normal validator reward if you successfully complete the mission. Those who partially (>50% failure rate) succeed will also get rewarded, but less.

Assumption:

• You make 40 XX in most recent era directly preceding the game era(s) (era 1106)
  • Assumption: node earnings 182 XX x 22% (maximum validator commission acceptable for this game)

Examples of earnings for two outcomes with rewards:

• Validator successfully fails 100% of cMixx rounds with the target during the game
  • Due to these failures you make 30 XX in the era (lose 10 XX, (40 - 30)). I will compensate you for the 10 XX
  • You will receive a separate bonus of 100% of your earnings from the previous era (40 XX * 100%)
  • My net payment to your address: 50 XX
• Validator fails between 50%+1 and less than 100% of the rounds shared with the target
  • Due to less failures than the more successful players, drop in earnings is maybe just 5 XX (40-35)
  • I will compensate you for the 5 XX and pay 40% of the earnings from previous era: (40 - 35) + (40 x 40%)
  • My net payment to your address: 21 XX
• Validator participates but is incompetent and doesnt' hit > 50% failure rate
  • They may lose 2-3 XX ("small success") or nothing (ineffective application of firewall rules)
  • They get no compensation and no reward, so if you can't take the risk just join the chat
  • I may compensate their nominators depending on the type and extent of screw-up (stupid screwups - no compensation)
    • Example of a stupid scrweup: you block IP address of the cMixx permissioning server instead of the cMixx ID you're supposed to

Separately, I will compensate all of your nominators for the difference (drop) in rewards for the era compared to the previous era.

Additional rewards may be dispensed depending on effectiveness of the game and if less than 10 validators participate in era 1107, the game will continue into era 1108 and I may increase rewards for the remaining slots in era 1108.

If five or more validators hit 100% failure rate with the target(s), I may give additional rewards to those five validators. I may also lower the criteria for above rewards if the target makes frequent changes to the IP address that make achieving these objectives hard.

Please check the rules and qualifying criteria.

Rewards for Space chat participants (non-validators welcome!)​

Contributing and silent observers are welcome to join the Space. Those disapproving of the game will be permanently blocked from the Space.

A reward of 30 XX will be given to most valuable chat participant in the Space based on quality of their feedback related to this game. Both validators and non-validators qualify and validators don't need to meet any additional criteria besides their validator application.

This will be evaluated between UTC 4:03am before the era until the end of the era (27 hour period). The number of messages sent must be more than one, but whether it's 2 or 20 will not influence the odds of getting this reward. Quality first, engagement second.

Please make sure to check the rules and requirements below.

Rules​

This is a bit complex, but it has to be because participants can apply and not participate. I could use multi-sig and a trusted co-signer to get minimum deposits for no-show participants, but this is easier.

Rules and crieteria for participating validators​

I have to share wallet addresses because everyone must be able to verify that all applicants are qualified. That's why I cannot accept applications via DM.

• First 10 qualified participants who apply will be accepted
  • If you see more than 10 submissions maybe it's not too late to apply - you may want to check those wallet addresses to see if the applicants qualify. If they obviously don't, submit your
  • As I check each application, I will comment and approve or reject until 10 have been approved or the era begins (whichever comes sooner)
• Objections regarding qualifications can be shared in the Space
• You may DM me with private questions
• No applicants details from DM will be shared or retained by me (whether or not you're accepted)
  • Note the xx Haven Space is public, so if you join the Space others will be able to see your Haven ID
    • You may join the Haven Space using a disposable Haven ID, submit your application, then leave the Space and optionally rejoin with a different Haven ID to monitor updates.

Criteria for validators​

The first 10 people who post their signed wallet addresses and meet the following criteria:

• Active validator in the era directly preceding "the era" (of the game)
• 22% or lower commission the era prior to, and during, the game
• At least 15K XX validator stake on the node in the game era (if you don't have now, you can bond before the era and unbond later)
• Not a pool wallet. Wallets from pool nodes or obvious node farmers with 5 or more nodes will not be accepted
• No nodes with recent history of > 25% commission as per xx Network Wallet (validator commission chart in the official wallet - see this example of a qualified node in terms of validator's commission history)

Note that some delays may happen in posting how many people have qualified.

Expected Haven message format for validator submission:

VALIDATOR
Address: <address>
Signature: <walletSignature>

See technical tips on how to do this.

Rules for non-validating chat participants​

Soft requirement: sign a XX wallet using the same wallet address.

• Those without a signed wallet may be blocked at my discretion
• Those without a signed wallet won't qualify for chat rewards (because I wouldn't be able to pay them)

Expected Haven message format for validator submission:

CHAT
Address: <address>
Signature: <walletSignature>

See technical tips on how to do this.

Payouts​

The payout will happen within three eras after the game era. Why so long?

Because I need to check thousands of rounds of the target node and make sure that participating validators have not participated in any of the successful ones. That will take time.

I plan to write a script that checks all rounds or (worst case) manually check a sufficiently big ample of the target's successful rounds and verify that each participant's node has failed more than 50% or all 100% of them in during the era.

Chat rewards will be dispensed promptly.

Technical tips​

How to find IP address for the validator?​

Search the cMixx log for cMix ID 0wjnYzegPz42ZZVc_dpB0RMRfddbEbdy_AkmsBbyrdMC or its substring:

cat /opt/xxnetwork/log/cmix.log | grep "Disconnected from 0wjnYzegPz42ZZVc"

If you can't find it, ask for help in the Space.

How to block and unblock an IP address?​

sudo ufw deny from <ip address>

How to sign your wallet address?​

Look at the screenshot or see this example.

• Validators: sign your node's validator's (not controller's) wallet address. From that I can see your cMixx ID for the game era, and check if meet the qualifying criteria. Validators are automatically qualified for chat rewards
• Non-validating chat participants: sign any wallet address (to which you hope to receive chat reward) using the same wallet

Based on the output in the screenshot above, the validator would paste this into the Haven Space:

VALIDATOR
Address: 6aCE19CakDJBp8wnVHB2HpHYfaeNiwx2RxQcsAcyWvPLVn5k
Signature: 0x9071685d1321e337a7e5b6bcecba433dc75ed18e5ac6e867fccb18ad2c1c31427757d241d021b6b8bcb5450472d65abb0ab5a261c4cfcd013ef089bd791a588a

Chat participants would just replace VALIDATOR with CHAT - the rest would be the same.

What happens to my validator if I participate?​

Rounds in which the blocked IP participates would fail due to pre-comp timeout. Other rounds will work fine.

If your node was to fail 20% of the rounds, you'd make close to 20% less, i.e. your validator earnings would drop by almost 20% of your commission (assuming your commission is 22% that would be 22% - (20% x 22%) or a drop of less than 5 XX).

Your nominators will be similarly impacted, but they'll be fully compensated as I've explained above.

Questions and answers about the game​

What happens if the target changes their IP address?​

There are several potential targets, so they're unlikely to watch our Space and change IP address before or during our little game. If they do, though, let's consider some scenarios:

• the target changes their IP address before beginning of the era: nothing changes for us. You may want to delete the outdated firewall rule and create a new one, and still earn partial rewards even if you do that hours into the game era - you just need to fail more than 50% of common rounds shared with the target
• the target changes their IP address after beginning of the game era: my reward criteria will likely be loosened, but you can still modify your firewall rules to make more
  • if they change the node IP eight hours into an era and you update your rule 10 hours into an era, you can still meet the objective for more than 50% of the rounds and get the second tier reward
  • if they change several times during the game era (which I can check in my own logs), rewards will be prorated for the longest stretch (e.g. 6 hours) between two changes will be considered. In that case your node would make normal earnings for 24-6 hours (as blocking would fail), and I'd pay out a quarter (6/24 hours) of rewards. For six hours of successful blocking on a node that made 50 XX in that era, I'd reward you 50 x (1/4) x 100% (12.5 XX) if all of your rounds shared with the target during those six hours failed

In any case, you and your nominators won't make less in the era unless you act completely incompetently and mess up your node.

How can I time the firewall rule to begin or end just before or after the era?​

Use the sleep command or use OS scheduler. For example, you can login as root (or a passwordless sudoer) and run the rule delete command after the sleep command.

sudo ufw deny ...        # enable blocking 
sudo ufw list numbered   # note the rule number
su - root                # passwordless suders don't need this
sleep 87000 && ufw delete ... # remove the rule (by the number)

Or simply just login tomorrow and remove the rule any time in the next era.

How does the nominator compensation work?​

In the era before the game, your node earns 190 XX. In the era, if you do well your node will earn less, let's say 160 XX.

I will compensate your nominators for that difference (which would be (190 x 22%) - (160 x 22%)).

I will check every winner's nominators in the game era and send each nominator their ideal share of the loss. For example: if a nominator has 30% of all nominations, they'll get 30% of 6.6 XX (total drop of nominators' earnings after validator's commission is deducted).

What is the expected outcome​

It is to estimate the effect (reward reduction for bad actors and their nominators) and costs (drop in rewards for the rest of us) of a community action like this. It's a special take on Polkadot's spammering, so to speak.

Ideally I'd like the community to be able to hurt pools in a cost-effective fashion.

Alternatively, the network can use formal measures by the Council or democracy vote, but voluntary community action is vastly superior to that approach.

Is denying IPv4 access the best way​

It's not, but it's easiest.

Participants are free to use any way they want to fail rounds with the target.

Sample game workflow for validators​

Sign your validator wallet address using the same address as explained above.

Paste the address and signature into the Haven Space:

VALIDATOR
Address: <yourValidatorWalletAddress>
Signature: <generatedSignature>

I'll review and - at least two hours before start of the era - publish up to 10 accepted participants' addresses and name the target (example: cMix ID 0wjnYzegPz42ZZVc_dpB0RMRfddbEbdy_AkmsBbyrdMC).

Find the IP address:

cat /opt/xxnetwork/log/cmix.log | grep "Disconnected from 0wjnYzegPz42ZZVc"

Let's say this shows you the IP address is 1.2.3.4.

Shortly before the era begins, block the IP and note the UFW rule number:

sudo ufw deny from 1.2.3.4
sudo sudo ufw list numbered

After the era begins, use the xx Network Dashboard to confirm rounds are falling.

You may login or recheck the dashboard during the era to confirm the target is still using the same IP. If not, remove the existing UFW rule and update it to continue blocking.

You can do this to remove the rule in little over 24 hours.

su - root
sleep 87000 && ufw delete <ruleNumber>

Do not log out. If that is not secure, then use screen to issue the command and detach, or create a one-time cronjob.

Or you can login in the next era and remove the rule(s) with sudo ufw delete <ruleNumber>.

Login after the era to confirm the node is no longer blocked in ufw. Or keep them blocked, if you want to help the network.

Hop on the chat to get started​

Join ArmchariAncap Chat Space to ask questions, watch or participate!

• Admin: recruitAnarchicIntent
• ArmchairAncap's wallet used for (outgoing) payments: 6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn

• Intro
• What matters and what doesn't
• Why care about the Polkadot ecosystem?
• What opportunities are there?
  • xx coin in Substrate walelts
  • Universal Polkadot addresses
  • xx chain can work with many Polkadot projects
• Past and present examples and opportunities
• Take-aways

Ah, look at all the blinded people!
Ah, look at all the blinded people!

Eleanor Rigby wants cMixx used by the banks that have been
Lives in a dream
Dreams about use case which we all know won't get out of the door
Who is it for?

All the blinded people
Where do they all come from?
All the blinded people
Where do they all belong?

Intro​

I'm going to turn a few thoughts into a blog post because it should be on the Internet and stay there for a while. (Ironically, this won't be published soon as I'm still waiting for Github to tell me what I did to have my account suspended - but more on that once I find out!)

Claim: very few xx Network community members realize or highlight opportunities related to the fact that xx Network uses a Substrate-based chain.

According to this article, there's over 300 projects in the Polkadot SDK-based ecosystem.

What matters and what doesn't​

Dr. Chaum and the Team behind xx Network are well aware of the benefits of having a Substrate-based chain, but years after the launch 90% of community members are still mesmerized and distracted by the peripheral stuff.

What's periferal stuff?

It's both old and new things - the BIS/CBDC trials, the Charles Hutchison-Trump administration thing, digital voting in government-organized elections...

Why care about the Polkadot ecosystem?​

The Team of course knows the value of Polkadot ecosystem which is why they picked a Substrate-based chain.

But if one looks at what most people in the community are paying attention to, most don't appear to see it. They're blinded by the seeming ease of scroing bigly, or simply lazy to learn and so they tirelessly look in the wrong places.

Such as? Various quantum computing news, the Charles/Trump thing, rumored crypto payments on X, etc.

It is true that Dr. Chaum himself has participated himself in BIS/CBDC-related research and evaluations, but that's because he should. I wouldn't expect, or want him to build embedded wallets. He is focused on the tech behind cMixx and the best evagelist and promoter we have.

But the opportunities that Polkadot SDK offers to xx Network are many and significant.

• approachable: they're suitable for community and developer engagement. You and that dApp developer you know don't need a PhD in cryptography or deep understanding of the workings of central banks in order to use cMixx and xx Chain to create useful and practical solutions today
• immediate: some of my ideas for dDpps require mere days to develop and launch. I know because I've done some simple ones myself. They don't take quarters to discuss and years to develop, trial and put in production. You don't need to look for "investors" to fund their development. Imagine & implement!
• low-cost: in some cases, 7 engineer days to users and maybe even revenue
• permissionless: these opportunities are real and don't depend on anyone reaching out to Elon or some political figure doing us a favor (or even realizing that it'd be us doing them a favor)

I could go on, but hodlers are doing themselves disservice looking for opportunities in the wrong places.

How hard is it to realize that fiat currencies aren't meant to be transparent, decentralized or private? It seems very. It won't happen.

Yes, cMixx should be trialed with the BIS and central banks. Why?

• to show that it won't happen despite the tech being there. In other words, to expose central banks and governments so that everyone can see that it's not about technical challenges, "the tech not being there" or whatever other excuse they come up with
• to scientifically and practically prove that xx Network can do this for private/permissionless use cases

I'm convinced 95% of people in the xx Network community don't realize or disagree with the above two points. But these are the key points when it comes to choosing where to engage and contribute (especially since most of us neither connected nor qualified to contribute - and no, asking "wen" doesn't count).

If anything, post-quantum mixnets may be implemented by central banks and governments, but in order to hide their own inner workings from taxpayers and public debt investors.

In other words, they may implement them to hide and obfuscate transactions between central banks or between central banks and private banks with whom they do business. It won't be on xx Network or any other public mixnet or chain. Got it?

What opportunities are there?​

I hope I shouldn't need to explain, but given the visual impairedness of many in the community, I'll mention several examples:

• My recent posts on dApps and Hacktoberfest 2024 wins give some concrete examples
• Other opportunities (high-level only, as I may try to realize some of them):
  • Most Substrate-based (aka Polkadot SDK-based) wallets can access xx Chain
  • All xx Chain addressses are valid on almost every Substrate-based chain
  • Almost all Polkadot-related projects could use xx Chain and make use of cMixx (xx Network mixnet service)

I'll explore each of these claims, but feel free to skim through them if you understood what I meant to say.

xx coin in Substrate walelts​

If one has "a" Substrate based wallet, they can likely use it to hold xx coin.

Not a big deal, there are many wallets that work with multiple chains, right?

Yes, but you have to pick a wallet that supports two or more coins that you have which in many cases means some L2 and therefore L1 - often Ethereum, which has been stagnant. Sometimes, if you use two L2s, you may need two Ethereum wallets. Or maybe three if you also use another chain. Oops!

For bitcoiners, it's even worse because there's barely anything going on there in terms of useful decentralized applications. Anyone who uses crypto (rather than keep BTC parked and watch the number go up and down) needs one for Bitcoin and several for useful apps.

In the Polkadot ecosystem, there are many good L1 and L2 chains and apps. You usually need just one wallet to access all your tokens and NFTs.

That makes it easy to own XX token and enables cross-polination across Substrate-based networks.

Universal Polkadot addresses​

That first statement about xx Chain adddresses being the same across all Substrate chains isn't entirely correct as stated above - that was purposedly simplified.

What's valid across most Substrate chains is your regular wallet pass phrase and private key(s). SS58 addresses are different for every chain, but can be derived from the same pass phrase or private key(s).

Why should we care? Because you can have a Substrate wallet that uses a single pass phrase for (probably) any dApp in the Polkadot ecosystem.

An xx Network address looks differently from its Polkadot "representation", but these are - and must be, to prevent confusion and loss - because these are different SS58 networks. That is amazing.

xx chain can work with many Polkadot projects​

Because of the two earlier points, Substrate L1 and L2 chains and apps can be easily interconnected.

What if I use Kusama and need to pay for cMixx "postage" (i.e. "premium" service tier, once xxPostage becomes available)?

I'll need only one wallet, just one pass phrase, KSM (tokens) and the ability to buy and sell XX tokens on a DEX to pay for "postage" on xx Network. cMixx postage hasn't been implemented yet, but the only thing that's missing is the ability to buy/sell XX coin with KSM which is technically possible today (e.g. see Hydration) and only a matter of making a small-to-moderate implementation effort.

What if I use XX token and want to use for some non-zero cost service on one of the many Substrate-based chains?

The same thing - one wallet, one pass phrase, and the ability to buy/sell other Substrate tokens - directly or indirectly (e.g. sell XX token to buy DOT or KSM, then sell DOT or KSM to buy the Substrate L1 token you need).

Until direct or indirect on-Substrate-chain DEXes that support XX token become available, one can still do this by using a DEX outside of the Substrate chain ecosystem, but for that we need a wallet that supports said DEX. At this time the easiest way to buy/sell in either direction would be to use a DEX and Ethereum-based wrapped XX coin. That's not perfectly convenient, but at least it doesn't require much overhead - it takes minutes at most.

For free services on Substrate-based entworks (where there's no need for buying and selling) - you can access them as soon as they're implemented. For example, the token- and asset-gated acces demo app only requires ocassional, potentially one-time transfer or transaction and you're good to go for months if not years. Some don't require any, for example in the case a site lets you access it with any Substrate-based token, as long as the USD equivalent of your balance is more than 10 dollars.

Past and present examples and opportunities​

In addition to the dApps I wrote about recently, I want to highlight one opportunity which I thought was real, and that was to evangelize and popularize the integration with Crust Network, a Substate-based network storage project.

xx Network added a Curst Network files app to the official xx Network wallet, but most people didn't pay attention or didn't want to think about it, so the feature wasn't maintained or improved and now it doesn't work (it appears Crust Network no longer maintains that pallet/API).

Crust Network isn't equally private and post-quantum resistant, but it's convenient and not less private that 99% of other chat apps let you upload "attachments" or inline images.

What if the idea didn't make any sense? Was it practical and usable at all? I've no doubt it was.

• Text - and Crust Network download links - go to cMixx
• Blobs (memes, audio clips, etc) go to Crust Network storage nodes and can be downloaded or shown inline in cMixx chat app

You lose some privacy for such binary data, but that's a low-cost tradeoff. In return we could have had "unlimited" size attachments in cMixx chat apps for 2 years now. But no one showed much interest and we still don't have that feature in Haven today.

While Crust Network is now out of the focus due to low interest, similar opportunities abound so I know what I'll do - I'll be looking at other opportunities in the Polkadot ecosystem because they're approachable, immediate, low-cost and permissionless.

Proxxy is another low-hanging fruit. As a reminder, it proxies chain RPC calls through cMixx, which means once a Substrate-based chain becomes supported by Proxxy, many Substrate chains could be supported within days. xx Network's cMixx mixnet is free to use and there's 300 projects that could add this "enhanced privacy" feature easily. And maybe just four-five wallets would have to be enabled to add this feature to hundreds of Polkadot SDK-based projects, to put it another way and tie with those earlire points mentioned above.

Proxxy originally focused on Ethereum wallets and just like with Crust Network integration, the community thought it's better to focus on those "high-profile" use cases I find unlikely to happen. I think Proxy should focus on Substrate-based chains instead.

Take-aways​

Many dApps from the Polkadot ecosystem could be used directly from xx Chain wallet and many Substrate chains could have a privacy setting that flips their wallet RPC transactions to use cMixx even if they don't pay for it with xx coin. That works today.

The lack of a mobile Haven client - once XX Messenger was discontinued - has been hindering such dApps and integrations, but thanks to one of the winners of Hacktoberfest 2024 now we have a responsive Haven application that works from Android clients. It doesn't work great (it's not power-efficient on mobile - those improvements need to be added), but it works. If your mobile device connects to cMixx periodically - for example to download notifications or batch-upload data - there's no problem to do that on Android today.

If we look in the right places, and those places are not in central banks or governments, opportunities are plenty.

I look forward to seeing - and maybe even creating some related PoCs - some cool Polkadot ecosystem integrations happen in 2025.

• xxblockdumper
• Using with xx chain
• What does this all mean
• Conclusion

xxblockdumper​

xxblockdumper is another nice utility from Rick.

It aims to provide the following features to xx chain users (from current repo description):

• Fetch complete block data from any Substrate-based chain
• Retrieve state data and extrinsics
• Export data to JSON format
• Support for latest or specific block numbers
• Configurable node endpoint
• Built-in retry mechanism with exponential backoff

Using with xx chain​

Download, install, use.

Three comments regarding today's main tree:

• Currently click.echo(f"Debug - Block structure: {json.dumps(block, indent=2)}", err=True) causes SCALE codec malfunction, so I mark it out before installing (this will probably get fixed soon)
• I've updated some packages before installing, including Python Substrate Interface and SCALE codec, but this will probably be updated in main soon
• -n ${BLOCKNUMBER} is optional and None means CURRENT
• You may see this error as well

$ blockdumper -n ws://192.168.1.3:63007

Connecting to node: ws://192.168.1.3:63007
Fetching data for latest
Block hash: 0x610dfaf8cfae9c0cc7478183e490cf38f56c497f48b9dd744b5fec9f20777bde
Error fetching state data: {'code': -32702, 'message': 'Response is too big', 'data': 'Exceeded max limit of 1048576'}

Yeah.

Change your xx chain configuration to allow large responses and restart chain service. Here the maximum response size is upped to 32 MB.

  --rpc-max-response-size 32 \

You need to be careful with this on servers that provide public services - this can get "expensive"!

As you can imagine, Dwellir's public RPC endpoint hasn't made those adjustments for your freeloading convenience.

Full console output:

Fetching data for latest
Block hash: 0x463b0a5145b3a2b5b8d10e5572122a554f0eb9772712a787b4a6ffd2edc1f2a0
Found 150325 storage keys
Fetching state data  [####################################]  100%          
Fetching extrinsics  [####################################]  100%

Output file name is currently hard-coded (block_<number>_<timestamp>.json) because xxblockdumper was created to enable simple DIY auditing of individual blocks.

In my case it was saved to ./dumps/block_15567031_20241110_155449.json.

What does that dump file look like? Like this. 52 MB JSON in this particular case.

{
    "block_data": {
        "block_number": 15567031,
        "block_hash": "0x463b0a5145b3a2b5b8d10e5572122a554f0eb9772712a787b4a6ffd2edc1f2a0",
        "state_root": "0x2218a4590b9906c25b5ad251379db00fcea731450bdc8a1adfebf640d04a41ba",
        "extrinsics_root": "0x47480d63db002bcbbebb44b37077cedc9624949fda470aa3ce72be8de0d306ca",
        "parent_hash": "0xd275c4801726c9ea7f69aea84ccb0d392e0b4dbfbb45dd8d8fa86c62174f0e27"
    },
    "state_data": {
        "0x1809d78346727a0ef58c0fa03bafa3231d885dcfb277f185f2d8e62a5f290c8500899da26b8497b0eaf20675a608ec9d7a7fa0f71648c62291d8ddbfe020a0675a70fe6788aa21d9": "0x04b26ce6317a87d3d9fdebe0362b568803e2057989d2fab2aa958870b57680c3670400000000406489aa040000000000000000000000",
    ...
    }
}

It needs to be further analyzed.

extract.py (currently just a stub in the repo) is to-do item that will contain a specific example for which the utility is being created. It will be executed against the dump file(s) to perform extraction, decoding and reporting.

$ python3 extract.py

What does this all mean​

It means you get detailed chain info off your xx chain server in the convenient JSON format.

It means you can use this for certain things without having a big chain explorer at your disposal.

It means you may not be able to react as quickly as by API-querying an explorer - as you can see, it takes a bit more than 6 seconds to get this stuff out of your RPC endpoint.

If not all data are requested, it may be possible to provide near-real-time watch services (for example), but I haven't verified this - I just imagine if a fraction of data is required, certain queries could be done in seconds.

On a fast server we could run multiple xxblockdumper tasks, but as long as each task takes more than 6 seconds to get data and analyze it, that can't work for near-real-time analytics - for that you'd need a different tool.

If you want to dump details of old block data you'll need to run your node in archive mode and have > 200 GB of disk space to play with. Nodes discard state fairly quickly depending on settings (minutes or hours).

For example, my dump file above contained many entries like these:

"Error fetching storage: 
{
    'code': -32000, 
    'message': 'Client error: UnknownBlock: State already discarded for 0x463b0a5145b3a2b5b8d10e5572122a554f0eb9772712a787b4a6ffd2edc1f2a0'
}"

In order for xxblockdumper to work you need an archive node.

Alternatively, if you look for current or very recent blocks and have a fast system, but state pruning timeout is 256 blocks, so for 1 hour you'd need (60s/6bps)x60 min= 600 at least.

./xxnetwork-chain -h | grep pruning
      --state-pruning <PRUNING_MODE>
          Specify the state pruning mode [default: 256]
      --blocks-pruning <PRUNING_MODE>
          Specify the blocks pruning mode [default: archive-canonical]

--blocks-pruning archive is what will always work, but xx chain node will need hundreds of GBs, possibly on flash media.

Conclusion​

xxblockdumper provides convenience to Python users who want to work with xx chain block data.

There are minor bugs that will be sorted out and then we'll be able to use it to build other tools.

• Intro
• Building blocks
• Building dApps for xx Network
  • Feature-full native chain
  • Native currency
• Use cases for these building blocks
• Is that legal
• Summary

Intro​

As Hacktoberfest 2024 just finished and I've churned out some more or less coherent stuff for it, I want to share a few very short additional notes about it here.

Building blocks​

xx Network has a mixnet (which in turn has an SDK called xxDK) which applications use to work with cMixx.

xx chain is a Polkadot SDK-based (aka Substrate-based) chain which has its own ecosystem, libraries, API.

Applications can use xxDK to send messages on xx Network for free, so there's no need to write to xx chain or own XX coins. It is expected that only power-users may have the need to buy XX coin to pay, which is to say casual use should never require anything but xxDK.

What does that mean for dApp authors? I think that means xx Network is a good platform for messaging dApps.

Building dApps for xx Network​

Usually the fact that xx Network is "bootstrapped" in a blockchain elicits negative comments (see these examples), if any at all.

Most people have no opinion about that, which isn't much better. It's a major difference and has to be considered. If you have good reasons why being blockchain-based is bad, that's fine as well.

I think it has a very positive impact that may not be obvious if you haven't thought about it and all you've heard is "crypto is full of scams".

For example, I happen to think that xx Network (and the Foundation) has a better setup than Signal and their foundation. Let's take a look at some more practical differences between xx Network and chainless apps.

Feature-full native chain​

xx Network is are one of very few networks that provide anonymous messaging and have its own L1 chain to work with.

xx Network has a good (Substrate-based), fast, low-cost chain with plenty of features - from assets to governance - so for many use cases entire apps can be written to it without using anything else.

Most other decentralized private messaging guys have to write dApps for 3rd party chains - which we can do, too - and we do not. More choice.

The PoC code for XX token- and asset-gating of Web sites shows how easy Polkadot-style dApps can work with xx Network - it wasn't too hard to modify the app for xx Network and add asset-gating. It would also be easy to modify that code to use asset-gating on other Substrate-based channels with asset support.

Native currency​

Most other private messaging apps don't have a native currency, so they have to pick a wallet and integrate with another chain.

xxDK dApps can do that as well, but it's simple enough to use xx chain, especially if you need to handle postage that I mentioned earlier - in that case your app may be able to use one wallet and one currency.

Once XX coin gets listed on a DEX, it will be easy to acquire XX coin with any major crypto-currency and use it to pay postage (when it becomes available), so using xxDK from a dApp that defaults to other coins isn't any different from using other similar networks.

Use cases for these building blocks​

I mentioned some of them in the token-gating post, but I'll make one additional example here to illustrate why I worked on those "building blocks" recently - we can put them together to build some simple dApps (or semi-dApps).

• It is easy to download a file, but if you need to do it reasonably privately, you can use Tribler
  • The challenge is getting the link equally (or more) privately
  • Find me in my Haven Space, pay me some coins, and I'll seed the file for you in Tribler (and give you the link). I can automate this completely as I explained in the Hacktoberfest post, or I can make it fully manual (which is necessary for on-demand items), semi-automated, or AI-powered
• If you need even more privacy for downloads, you can park them on S3 and use an asset-gated Web site in the public cloud
• If you need even more privacy, you can run xx Haven container and Web service on Onion network
• If you want to use a Web3 app without using public cloud, you can create an app that uses xxDK for chat and something like Crust Network to share content

With XX chain (or other Substrate-chain) asset-gating we an even serve the same content using different routes (links) for different membership levels all on xx Network.

Is that legal​

Of course, some will inevitably think "crypto is only good for scams and crime".

I wouldn't be posting about this if I couldn't think of a lawful use case.

There are valid use cases for rare or unique data that can't be free (because it may require 100s of GBs in egress bandwidth).

There are dApps that specialize in blobs (Storj, etc.), but there are use cases where data has to be posted on demand.

In other cases you may not want to charge for egress in dApp, so you could use Tribler. Or you may want to speed up seeding in an ad-hoc manner, which is very easy to do in a community-powered way. Put a file on Tribler, share the link in a Haven space and ask everyone to help out:

• no crypto-currency involved
• zero barrier to entry - one free app to install (Tribler), no wallet to create, no DEX/CEX or any registration to use

So, it's not at all true there are no lawful use cases here.

xxNetwork cMixx is used mostly to share links or other metadata that benefits from its PQE and mixnet. It could be used for paid access to low-bandwidth data feeds, but I did not consider such use cases in this post.

Legal uses with P2P payments are also possible. In xx Network validator community there have been multiple occasions where people needed to download a copy of xx Chain faster than xx Chain could download it on its own: if you don't get ready by next validator election deadline you may not get elected and lose 50 XX by not validating, so paying 25 XX to get it faster would have saved validators money.

Storj egress is $0.007/GB, so 200GB is $1.4, and about $0.8 to upload. $2.2 is still very cheap, but with some friction for both sides (Storj account setup, payment, setup).

Haven-Tribler:

If they were Solana validators they would pay with Solana because that's what they already have ready to go. That doesn't change anything.

Summary​

So we have everything you need and there's no need to use any other network, right?

Wrong! I'm not an XX coin maximalist, folks.

I'd never "encourage" you to use or buy XX coin. If you - a user or developer - think that it would help you, use it.

I only want to share why I think xx Network mixnet is quite unique in its approach. It does give you more flexibility and more convenience.

Anyone can build for xxDK and use (or not) whatever crypto currency they like in their dApp. They can also use several - for example:

• some currency which is their first choice
• XX coin for xx Postage
• Crust for blob storage
• Ethereum for ENS (name and reputation)

Any permutation of these will work, and not having any coin will also work (Haven + Tribler, for example).

With just a couple of building blocks we can build reasonably private dApps.

Some other building blocks I'd like to see (not a complete list):

• Reputation (maybe through Ethereum ENS)
• Identity (maybe on Polkadot or Ethereum ENS) for easier
• Blob app integration (add xxDK chat to Crust app, or run Haven + Crust in the same browser tab)

If you have own ideas, check out the xx Foundation Grant program or reach out on X or the XX Discord.

• Tokens, assets, NFTs, WTF
• Token-gated access control
• Asset-gated access control
• Query (check asset balances)
• Buying and selling assets on xx chain
• Dealing with subscription expiration
• Use cases
• Alien assets and NFTs
• Summary

Tokens, assets, NFTs, WTF​

xx Network has its native currency XX coin, assets and NFTs. Unfortunately, XX is referred to as a "token" (not a currency).

Most of the Polkadot SDK-based chains promote NFTs, but xx Network hasn't adopted those - at least not in the official wallet.

But we can issue and use assets, which is a sensitive term (the SEC, etc.) even when used in non-asset contexts like this one.

To me XX coin is a currency, and "assets" are tokens, but this confusing official terminology is something we have to deal with.

Token-gated access control​

I modified a Kusama example for xx Network (xx chain) and made it available here.

It checks the balance on the address in your Polkadot.js wallet and depending on that value it allows you to access the site.

That's great, so all Substrate-based chains can do this and limit access to apps to hodlers or whales, etc. You don't have 100xx in your wallet? Piss off!

But what about them "soulbound tokens"?

That's a different lookup/API, for "assets" rather than "token" balances (for XX).

Asset-gated access control​

We can also limit access to hodlers of certain assets, and by that I mean token-like assets available on xx Network.

In the case you've been so engaged that you missed their existence, you can find them in xx Network Wallet under Network > Assets.

Let's consider two, test (ID: 4) and Intelligence (ID: 42).

We need to know how to query their balance in user's wallet.

For the impatient JS users - find sample JS code in the same repository.

Query (check asset balances)​

It's unbelievable and ludicrous, but it took me many hours to find this info. As if no one needs this stuff.

I find that hard to believe! But look above - after several years of mainnet and there's just half a dozen test-grade assets, so maybe that's true?

Anyway, let's go:

from substrateinterface import SubstrateInterface

substrate = SubstrateInterface(
    url="ws://192.168.1.30:63007"
)

# Asset test
ASSET_ID = 4  # asset ID: test
ACCOUNT = '6Xo3ESdU9nW3iiAk5ZqDA7kKqYJMcJFGiRz91LkoZKvvTjAV' # owner / issuer
account_info = substrate.query(
    module='Assets',
    storage_function='Account',
    params=[ASSET_ID, ACCOUNT],
)

print(f'Balance: {account_info["balance"]}')
# Balance: 100000000000

# Asset Intelligence
ASSET_ID = 42  # asset ID: Intelligence
ACCOUNT = '6ZsMetbm4yoj9JQJdmhn2dKScFNkUnxULXwTBsNpmL1FM3KY' # owner / issuer

account_info = substrate.query(
    module='Assets',
    storage_function='Account',
    params=[ASSET_ID, ACCOUNT],
)

print(f'Balance: {account_info["balance"]}')
# Balance: 42

All right!!! I think this should work for other addresses (not just the owner) but I don't know if any of these owners have sent them to other people.

Hey, that issuance amount of test looks weird - how come there's 100000000000 of 'em when the screenshot says 100?

The reason is assets may have different properties. We can use TFM (where is it?) or try the "create asset" workflow to see what goes in.

So, it appears Intelligence is an integer-based asset, while test has a crapload of decimals.

That's good to know, but it doesn't matter much to us in this particular workflow: we don't need to know how to look up an asset's properties as we usually accept one or more known assets. If you're interested in that, however, find it here - it's api.query.assets.metadata (in JavaScript). Polkadot.js API details related to assets can be found in the repo.

In JS I managed to do this:

import { ApiPromise, WsProvider } from "@polkadot/api";
import type { StorageKey, u32 } from '@polkadot/types';
const assetDetails = await api.query.assets.asset(assetId);
console.table(assetDetails.toHuman());
const assetMetadata = await api.query.assets.metadata(assetId);
console.table(assetMetadata.toHuman());

.. and get this. But these are the details I don't care about much, as I've mentioned.

┌──────────────┬────────────────────────────────────────────────────┐
│   (index)    │                       Values                       │
├──────────────┼────────────────────────────────────────────────────┤
│    owner     │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│    issuer    │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│    admin     │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│   freezer    │ '6VXfntvzZTzY2YPA4KtSVZMx1YqPFTo7o8qtddNLB4K91Mcn' │
│    supply    │                       '102'                        │
│   deposit    │                 '100,000,000,000'                  │
│  minBalance  │                        '1'                         │
│ isSufficient │                       false                        │
│   accounts   │                        '3'                         │
│ sufficients  │                        '0'                         │
│  approvals   │                        '0'                         │
│    status    │                       'Live'                       │
└──────────────┴────────────────────────────────────────────────────┘
┌──────────┬──────────────────┐
│ (index)  │      Values      │
├──────────┼──────────────────┤
│ deposit  │ '18,000,000,000' │
│   name   │      'JUNK'      │
│  symbol  │      'JUNK'      │
│ decimals │       '0'        │
│ isFrozen │      false       │
└──────────┴──────────────────┘

I got lucky with api.query.assets.account(assetId, accountAddress) hours later.

I used the issuing address to mint 1 JUNK to a beneficiary address.

assetId = 5 # Asset: JUNK
accountAddress = '6aCE19CakDJBp8wnVHB2HpHYfaeNiwx2RxQcsAcyWvPLVn5k'
const accountInfo = await api.query.assets.account(assetId, accountAddress);
if (accountInfo.isEmpty) {
  console.log(
    `No balance found for asset ${assetId} and address ${accountAddress}`
  );
} else {
  console.log(
    `Account balance for asset ${assetId} and address ${accountAddress}:`,
    accountInfo.toHuman()
  );
}

Log:

Account balance for asset 5 and address 6aCE19CakDJBp8wnVHB2HpHYfaeNiwx2RxQcsAcyWvPLVn5k:
    { balance: '1', isFrozen: false, reason: 'Consumer', extra: null }

My Github repo contains a working code example. It's poorly written but it works and you may be able to improve on it.

The Wallet has some smart examples in these files, but they're too smart for me - I could't figure out how to use them.

• packages/page-assets/src/Balances/useBalances.ts
• packages/page-assets/src/useAssetIds.ts
• packages/page-assets/src/useAssetInfos.ts

Buying and selling assets on xx chain​

Houston, we have a problem... I'm not sure how to do that.

OTC to the rescue! Create and publish Haven Space address for your OTC store and sell assets there. It sucks, but it can be automated. How?

You can build a bot - I once created a crude one - that reads comments in your channel and sells this stuff.

Price list for your Validator Monthly Intelligence newsletter:

• Basic subscription - 10 XX/mo
• Premium - 100 XX/mo

Buyer says "I've transferred 10 XX (extrinsic hash attached), please credit me 1 Intelligence to this address 6ZLG..":

/buy 1 Intelligence 6VwDT9VMgPrswqtJtqUH4PU7DkcaHggJjyjnkuUZyNA5c5j1 \
    0xaba65810f33f905e2d136e6a12c0a7e4ae7111a4f6c59415ffa83a3d0d7663c0

The bot checks that transaction (everything checks out, 10XX received). It mints 1 Intelligence to 6ZLGrh6Mu7uDioL7bAVS4kTsRSez7w1Lz18fiApUqRHNWnxd and appends an extrinsic hash and timestamp for easier troubleshooting.

/mint 1 6VwDT9VMgPrswqtJtqUH4PU7DkcaHggJjyjnkuUZyNA5c5j1 \
    0xaba65810f33f905e2d136e6a12c0a7e4ae7111a4f6c59415ffa83a3d0d7663c0 {timestamp}

If something fails, Haven keeps data for 21 days so there's enough time to chit-chat in another Space (for human-powered support) where refunds and other issues can be dealt with.

I'm sure there are some edge cases I haven't thought of, but there's no reason why this can't work and there must be some detailed production-worthy examples in other ecosystems.

Anyway, let's move on. As Teddy KGB said, "Pay him... Pay that man his fxxxing money". Or send the man his freaking asset:

from substrateinterface import SubstrateInterface

KEYPAIR = '....'

# Asset: Intelligence
ASSET_ID = 5  
ASSET_QTY = 1
# Subscriber's wallet to use in Polkadot{.js} for authorization
SUBSCRIBER_ID = '6VwDT9VMgPrswqtJtqUH4PU7DkcaHggJjyjnkuUZyNA5c5j1'

call = substrate.compose_call(
    call_module="Assets",
    call_function="transfer",
    call_params={'id': ASSET_ID, 'target': SUBSCRIBER_ID, 'amount': ASSET_QTY}
)

extrinsic = substrate.create_signed_extrinsic(call=call, keypair=KEYPAIR, era={'period': 64})
result = substrate.submit_extrinsic(extrinsic, wait_for_inclusion=True)

I haven't tried this one yet, by the way.

I'm not sure about the difference between minting and transferring - obviously the former increments the issuance while the latter sends existing, but I haven't looked at the minting API in Python yet. I wonder if minting is a term for asset transfer (I hope not, as it implies additional issuance).

Dealing with subscription expiration​

Yes, there are more problems...

Next month that guy will still have his 1 Intelligence. But we need to charge him again. What can we do?

Normally we'd use "Smart Contracts", but we can't (or at least I don't know how to do that on xx chain), so we have to come up with workarounds such as:

• Check for a new token (Intelligence-Jan, Intelligence-Feb) every month (you can pre-release, and not sell, 12 of them at once), or
• Sell 12 month subscriptions and issue a new asset every year , or
• Buy back tokens at a tiny fraction of the original price, or
• Check date of last pay the wallet did as well as the balance (complicated)

Use cases​

Few wallets have good reputation, but there are folks out there who could probably charge for monthly subscription.

• Newsletter (say, monthly validator analysis for stakers/nominators)
• xx chain-related reports (nominator pays 10xx for staking payouts and Web reports/stats, for example)
• Discord bots for asset-gated access to special channels
• Private training/consulting (for Haven admins and users, e.g. 1 unit of an asset buys you 1 minute)
• Classic "soulbound" assets given away for free (no OTC trading necessary)

Managed Haven instance hosting sounds like another possibility, but that idea sucks:

• It requires absolute trust
• Users who access such instances immediately identify themselves by their wallet ID (and xx is not a privacy coin) and maybe IP address, browser fingerprint and more

Alien assets and NFTs​

Polkadot has a rich asset/NFT ecosystem that can do more and even has bridges to other L1 chains (alien NFTs, one might say).

While that's nice, it's more than we need here.

Of course, xx chain could adopt some of those features, but I think it objectively doesn't need them.

Summary​

In xx Network wallet NFTs are there (based on the xxchain code pallet-nfts v4.0.0 is used), but there's no way to issue them from the wallet. You can find the NFT Pallet documentation here, just mind the fact that xx Network Wallet won't let owners see them unless wallet itself gets some upgrades.

As we've seen assets exist, but aren't likely to be used as "assets".

The xx Network community hasn't done much to monetize Web (or should I say "Web3" to highlight my "DeFi" prowess) access.

One of the reasons is surely lack of examples and documentation, and another is a small market size.

With XX coin-gated and NFT-gated apps (based on xx "assets"), that is easy to do now. Get the code here.

Market for xx chain-related token- and NFT-gated services (based on xx chain "assets") is still small, but it does exist. Anyone who builds something and makes it available for others, lowers the entry barrier for more xx Network services. Let us hope such services emerge in coming months.

• Introduction
  • Wait, I can't run Haven on mobile?
• Notes
  • Notification if contact's fingerprint changes
  • Find/add contacts
  • Supported push notification services
  • Legal jurisdication
• Conclusion

Introduction​

Today I forked and published a comparison of various messengers. Why?

Because as the author of the original comparison can't possibly include everything (he actually checks and compares all those details, which requires non-trivial efforts) and he focuses on major messengers so Haven't currently isn't included. (He welcomes requests, so you could suggest Haven - Haven't (pun intended).)

Not having a mobile version probably doesn't help.

Wait, I can't run Haven on mobile?​

As of today, yes. I mean, you can run Haven on mobile Android and Linux devices with WASM-capable browsers, but the UI isn't responsive and it doesn't attempt to save battery, so it won't be pretty.

xx Messenger was a mobile app that would probably have done well in a comparison, but it used an older xxDK and is no longer maintained.

Haven is the main reference application for xx Network confidential & private messaging. There's a patch for responsive UI which was delivered as part of Hacktoberfest 2024 activities, but it hasn't been merged yet. Keep an eye on that in coming weeks - if merged, that would make Haven more suitable - although just the UI - for Android browsers with WASM support.

Anyway, back to the main topic, which is I wanted to create a post with some notes regarding the Haven column in that comparison page.

Notes​

These are notes that clarify some of the values I picked for the Haven column in that comparison chart.

Notification if contact's fingerprint changes​

Most people have tried Signal. If you swap your phone or such, your Signal chat counterparts will be informed that your "fingerprint" changed. There's no such thing on cMixx (and in Haven).

Haven identity is the only user-facing cryptographic identity.

You can't ""change" a fingerprint or anything like that. If you lose access to your identity (forget the password to encrypted identity file, or lose the identity file), you must assume a different identity. In that case there's no mechanism for you to rejoin a private Space (1-on-1 or group chat) and message contacts saying "this identity replaces this other identity". Who can tell if that's the same person?

If you have backups of the invite links and pass phrases you can rejoin those spaces using the new identity. But there's no way for others to know if the new identity is owned by the same person.

The only way to do this is to use the old identity to message everyone "from now on, I'll be using this new identity".

Another way is to use an external identity service where people can look up identities you claim on xx Network. But that assumes they know your external identity.

Find/add contacts​

See the previous point - there's no name service in Haven, so you can't "find" anyone.

You can use external identity services mentioned just above.

xx Messenger had this custom IDs, but Haven does not. Personally I don't miss those - I think external ID services are the way to go because messenger contacts are just one of many things you need to have an address book for.

Since Haven is one of few messengers that is anchored in a blockchain, knowing someone's cMixx name is not enough. We want their wallet addresses (probably not just for xx coin, but for several currencies), their ENS name, and other public Web3 data they choose to publish.

Why you can't "add" contacts either? Well, we'd need to sync them somewhere. xx Messenger could upload (backup) its data to S3, so contacts could be saved as well.

xx Haven currently doesn't do that so contacts must be searched in external services where people publish their Haven identities. That location is a matter of choice as well - not just in terms of usability, but also privacy, cost, and more. Having to publish your data on ENS (and pay that fee) may or may not be liked by all users which is why I think Haven should leave those integrations to other cMixx messengers when they appear. I don't mind looking it up in whatever way is convenient for me and my contacts.

Supported push notification services​

xx Messenger used a centralized push service, but Haven doesn't currently doesn't have it which means it's limited to constant polling which is power-consuming.

That doesn't matter much for desktops (there's more "unnecessary" activity from Cover Traffic than from notifications), but matters on mobile devices.

Legal jurisdication​

The xx Foundation is a non-profit in the USA.

Mixnet round scheduling is done by the Foundation and that server is - if I'm not mistaken - in located the EU. The scheduling node isn't involved in data handling.

Client-side ecrypted user data has five copies per each cMixx round and so user data from each conversation lives in dozens of jurisdications (see the cMix dashboard). The scheduling server doesn't know which messages went into which mixnet round - only the sender and recepient(s) do, so those not included in a conversation wouldn't even know where encrypted data is.

Encrypted data is kept on cMixx gateways for 21 days after which only local (cached) copies may remain on participants' clients.

Conclusion​

I obviously don't speak for the author of the original document, so the values I picked for Haven are my own.

This post elaborates on all the rows where I felt felt sharing some notes would be helpful. If the original author reviews and adds Haven to his document, I may or may not update my fork (I wouldn't if I completely disagreed with this evaluation, for example).

I have some other comparisons in other blog entries - you can search the site for "comparison" to find them.

Hacktoberfest 2024 is over so here's what I did:

• Added search function, keywords and front matter to 67 pages on https://learn.xx.network/. Usability, SEO, etc.
• Repurposed existing sample code for Kusama to create token-gated site for xx coins which can help anyone who wants to build toke-gated sites. Note that this works only for xx coin, but assets aka NFTs on xx chain would need additional work as asset (NFT) lookups are more complicated.
• Published two simple PoCs for Haven-Tribler integration
  • one runs Haven in a Tribler chat frame (I tagged it "v1.0") - more secure, but less convenient (as always...)
  • another runs Tribler in a Haven iFrame ("v2.0")
  • both can be found here and there's a blog post about the motivation, use cases and approaches
• Published a toy extension for Firefox - see the Tribler-with-Haven blog post for more, and a screenshot is below.
• Updated User and Admin guides to xx Network Haven

Apart from the "common good" contributions (xx Network Learn, etc), the rest was centered around exploring Haven integrations with Tribler.

This screenshot sums it all up - Tribler in Haven iFrame (aka my "v2.0") - and the toy Firefox extension in action!

• Find a Magnet link in a Haven space
• Select the link, right-click on it and use the Firefox extension download it from Tribler
• Watch download progress without switching to other (browser) tabs or windows

If you use a non-Mozilla browser you can copy the link and add it to Tribler as usual.

I haven't had time to do a Chromium-based extension yet.

• What's Tribler?
• What's Haven?
• What integrations, and why?
• Integrations
  • Pros and cons of DIY approaches
  • Do we actually need any integration?
• Security concerns
• Summary

What's Tribler?​

It's an app for Tor-like Torrent-based file sharing that doesn't suck like Tor does.

What's Haven?​

It's a privacy-focused, decentralized chat and messaging Web app on xx Network's cMixx mixnet.

What integrations, and why?​

Let's see about the whys first: you need to find torrents that you want to download.

Tribler has internal search feature but it's not that good yet.

So you go out on the Web to find torrents, which means one or more of the following:

• Being tracked on Torrent search Web sites
• Monetary (and sometimes privacy) cost of subscribing to VPN service
• Using Tor to hide your activity
• Registering at Torrent sharing private Web sites or chats
• Using some password-protected site where you're registered with a fake or real identity

Is there a better way? I think there is: one UI with Haven and Tribler:

• Someone posts RSS feed into a private (or public) Haven Space ("chat channel")
• Users copy links and download them using Tribler

Integrations​

Ideally, Haven could run inside of Tribler. But the Tribler project would have to make that happen. Alternatively, someone could create and maintain a patch. Not very good.

Another way is to create a small patch to Tribler menus and run Haven in an iFrame.

Another way is to run Tribler in a Haven iFrame. That's easier, but you have to create a small patch for Haven, which some privacy-sensitive people may not like.

Pros and cons of DIY approaches​

A Haven iFrame in Tribler chat menu is available here. I call this attempt v1.0.

You click on the chat cloud icion and Haven opens in the main pane (iFrame).

• Step 1: join a Haven Space ("chat channel")
• Step 2: find a magnet link
• Step 3: paste it into "Add torrent"

The bad:

• every time the user navigates away from the chat menu, Haven state is lost and user cannot access Haven again without logging in

The good:

• every time the user navigates away from the chat menu, Haven state is lost and user cannot access Haven again without logging in

Do you see what I mean? If your use case is "get into a Haven Space, get one link, copy it to Tribler and leave Haven", this is actually a good approach. All it takes to secure access to Haven is to navigate away: you won't leave Haven iFrame open because in order to use that Magnet link you'll have to leave it. Just make sure your Haven profile password is strong!

Note that this only hides your Haven identity, Spaces, and chat data, while Tribler UI is still running and downloaded data is on disk.

The second approach I tried - a Tribler iFrame in Haven - works the other way around, except there's no state in Tribler (it's a server-based application with a Web UI) so if you download multiple torrents or like to chat with Space members as you download, this may be better for you.

Join a channel, get your links, download them in Tribler and watch/manage downloads as they go.

In this approach there's a small patch to Haven which seems low-risk to me if you're the only user of your Haven instance: you own the Haven instance and you own the Tribler instance as well, so as long as you're not concerned about Tribler in a Haven iFrame, I think patching Haven and using it this way is fine.

I'm working on finalizing these small patches in another release at the same location as v1.0.

Do we actually need any integration?​

That's a good question. If you don't use both of these applications at the same time often, it's probably best to use them separately and avoid complications.

As an example of yet other approaches, I've built a simple browser extension which downloads selected (Magnet) links using Tribler: very easy to use, no patches required. But you can't see or control what's going on with downloads without going to another tab or window with Tribler UI.

I couldn't load Haven in this "preview" version of Firefox (WASM issues), but this is how simple the extension is: select a Magnet link in Haven chat and use the extension to initiate Tribler download.

This can work anywhere including the "Haven with a Tribler iFrame" approach because it simply talks to the Tribler API and Tribler UI doesn't need to be visible. It saves some copy-and-paste even if Tribler runs in the same browser tab as Haven. I've posted a proof-of-concept version here - see the link for the details.

If you're a security freak, I won't try to persuade you to use these iFrame approaches.

Security concerns​

It is possible that the app in iFrame does something to its parent frame. If you worry about that, of course just run the apps separately or even in different VMs.

In the "Haven with a Tribler iFrame" approach we could tighten the iFrame CORS, and also properly integrate applications so that we don't have to skip authentication from localhost clients on Tribler (which I currently do). I'll post the patches in the repo for easy reviewing. Risk of someone else accessing your instance of Tribler on localhost (where Haven is running) through Haven iFrame should be extremely low, though.

And this instance of Tribler should not listen on public IPs - simply close off its Web UI and IP ports.

If you want to let others access Haven on the same computer, you could simply start another container binding a public IP and port. The same goes for extra Tribler instances.

In a crazy mix-up setup you could run a "groupware edition" of Haven-Tribler compose.yaml:

• Haven-Tribler setup for multiple users (who all share same Tribler and can be in the same channel if they're all focused on same content)
• One Web server gateway sharing static content (Tribler download directory) for authenticated downloads

That would be as secure as the stupidest downloader.

Summary​

Haven provides private and confidential access to Magnet links that can be used in Tribler: free access, post-quantum E2EE, and metadata shredding eliminate the need to use Tor, VPNs or privacy-leaking Web sites.

Among DIY approaches at lightweight integration:

• For single-torrent and one-off use, Tribler with a Haven iFrame is a good approach which forces inconvenience (and results in good SecOps)
• For parallel use (Haven + Tribler) and multiple downloads, I like Haven with a Tribler iFrame because it gives me full control over Tribler
• For "hidden Tribler" we can run Haven + browser extension that hooks into the Tribler API, but you'd want extra controls and visibility into downloads, which means either occasional access to Tribler UI or a fat extension with some Tribler indicators similar to "Down Them All" or such (which is complex).

bip-utils​

bip-utils allows generating mnemonics, seeds, private/public keys and addresses for different types of cryptocurrencies, including Substrate-based currencies.

xx Network support​

I added it to a fork here. You could make similar/same modifications to bip-utils and build it yourself, of course.

I'd have to submit a patch to upstream, but "generic" Substrate coins are supported as well, so you could use it the same way without "hardcoded" XX configuration in bip-utils. You'd need to specify a custom coin/chain configuration, though. In the fork, that's already done.

Use from Substrate and bip-utils​

Using Substrate:

>>> from substrateinterface import SubstrateInterface, Keypair, KeypairType
>>> from substrateinterface.exceptions import SubstrateRequestException
>>> kp = Keypair.create_from_mnemonic('abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about',ss58_format=55)
>>> kp.ss58_address
'6XcmqdSCi4Y4Qa4aVjqZRZbuB5P83CZ2XeuKnmtrd1DK75BL'

Using bip-utils, we follow the Substrate example from here:

>>> import binascii
>>> from bip_utils import Bip39MnemonicGenerator, Bip39WordsNum, Substrate, SubstrateBip39SeedGenerator, SubstrateCoins
>>> mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about"
>>> seed_bytes = SubstrateBip39SeedGenerator(mnemonic).Generate()
>>> substrate_ctx.m_pub_key.ToAddress()
'6XcmqdSCi4Y4Qa4aVjqZRZbuB5P83CZ2XeuKnmtrd1DK75BL'

Why "vs."​

It's not A vs. B, it's A and B, but the Nym Web sites make some biased comparisons with xx Network, so I'll do my own for the benefit of my readers.

What are Nym and xx Network?​

They're both blockchain-rooted privacy platforms.

• Nym Tech blog (they have different sites for the company, services, etc.)
• xx Network web site

But there are differences, so let's take a look at those.

Comparison​

This is how I see it.

I haven't compared VPN-related features because xx Network doesn't offer that service. You may want to do your own comparison vs. Mullvad VPN or other VPN service.

Blockchain​

This isn't important for end users, but Polkadot (used by xx Network) has a bigger ecosystem compared to Cosmos.

Governance and integrations seem better on Polkadot and that's why it's been relatively easy for xx Network to create integrations (bridge) with Ripple and Ethereum, for example. I expect this will continue simply because xx Network leverages a superior blockchain platform (Polkadot).

Validators​

Nym is still running a permissioned network that's smaller than xx Network's. In this regard, they're behind.

Perhaps out of necessity, Nym has a more restricted entry and exit conditions for validators. I actually like how they do this and I think it's better than xx Network. Highlights:

New validators can join via a NYM-to-NYX swap contract. The contract will not allow more than 1% of total stake increase per month to prevent sudden hostile takeovers.

The contract will only allow swapping NYM to NYX and will not allow exchanging NYX back to NYM. A NYX holder who wishes to sell their NYX stake will have to do so via OTC trades.

You may say this doesn't prevent indirect hoarding of coins, but at least at this moment (because the network is permissioned with KYC, it appears) they can control this better. xx Network has some small pools that should be banned from the network, but the problem probably isn't significant enough to motivate the community to move against it.

xx Network is permissionless as far as staking and identity are concerned. So, although Nym's rules and controls seem helpful, they may not be possible to implement on xx Network or a permissionless Nym network. We'll see how Nym adjusts to permissionless life (if they ever get there).

Services​

Nym provides a Wireguard-based VPN routed over their network, which xx Network doesn't do.

While this seems great - you don't need to buy Mullvad or other VPN subscription, for example - it's a trap.

Not for the users, but for Nym Tech and their community whose nodes provide that service.

I don't think they'll be able to pull this off because bandwidth requirements will be huge and there's no way operators who operate VPN entry/exit nodes can do that with residential connections. What does that mean?

That means SPs or the cloud, and that means they'll need to be paid.

But, now you have KYC + getting paid for VPN + risk of illegal use (which they can't really monitor because it's encrypted and censorship-free). Do you see where this is going?

Do you want to make $500/mo and deal with daily DMCA notices and maybe even police inquiries? Not many people do, unless they're based in a 3rd world country.

I don't know how they're going to pull that off. If I was them I'd allow only whitelisted destinations, but for most of those people don't really need to use VPNs.

We'll see. I'm skeptical.

Integrations​

I haven't done a deep dive on these, but:

• Nym is ahead in VPN-related integrations simply because there's not much to integrate and xx Network doesn't have that integration to begin with
• Mixnet integrations are hard to compare because they're dissimilar and each platform has a few so maybe it's fair to say it's roughly even

xx Network has wallet integrations through Proxxy (cMix-backed API proxy), while Nym's own wallet natively uses Nym's mixnet (and they have Zk-nyms), so in wallet integrations they're likely better.

Payments​

xx Network doesn't have blockchain privacy features. This decision was deliberate - I wrote about it here.

Nym has zk-nyms which makes it a privacy-capable coin and therefore a candidate for delisting (or harder listing) on centralized exchanges.

If you need a VPN, you can get Mullvad VPN and pay with Monero. If you're a Nym VPN user, then it appears you can buy Nym VPN credits with Zcash.

Both approaches work, but with Nym you can buy both VPN and pay for mixnet services with one coin. Now you may say "I prefer Monero and Mullvad", but that's a matter of preference and convenience.

xx coin, the native currency of xx chain, may add privacy features in the future but it's been de-prioritized to avoid regulatory and listing challenges.

One valid point in Nym's material is that you can acquire their coin and pay for services without being tracked. xx Network can't do that. At the same time, xx Network cMix service is still free, so there's nothing to pay for. You still don't need any xx coin to use xx Network in the first place!

Mixnet​

First, post-quantum cryptography (PQC) is a to-do item for Nym, and implemented in xx Network's cMix.

Second, Nym's network is still centralized, so every single validator is known. Said differently: Nym mixing is decentralized, but all the mixers are known.

Third, in their litepaper, they have a comparison between cMix (mixnet used by xx Network) and their modified 3rd party design (based on Loopix). I'm not qualified to evaluate that, so I won't.

And then there's this thing below. As a reminder: their litepaper was published (updated?) in 2023, so it's not like they've missed anything because it didn't exist in mid 2023.

In the table below they refer to Elixxir (which was the company behind xx Network/cMix early on) although xx Network has become foundation-managed years ago and Elixxir no long plays a role. Maybe using a prehistoric name is a way to say "we created that in 2019 and forgot to update". Well, you didn't and your litepaper was published on Nov 2, 2023.

Let's see:

• 1 - Incentivised relays - xx Network has had that for years. Validators stake themselves and get staked by other coin holders. They get rewarded for authoring blocks on xx chain and relaying cMix messages. In coming quarters postage for premium tier users.
• 2 - Scalable network - xx Network has almost 400 nodes - more than enough for its traffic needs - and it doesn't seem not scalable (or whatever is the opposite from scalable). For a mixnet focused on short messages (whether it's text messages or API calls), it seems scalable enough to me.
• 3 - Secure and efficient encryption protocol - As I've mentioned earlier Nym claims their approach has a higher efficiency which I am unable to judge, but they don't have post-quantum encryption so even it it's more efficient, is it more secure across the board? It's a blanket statement. Not to mention that xx Network's cMix was developed in-house by Dr. Chaum and is still being developed (this includes development for three Worldcoin grants), while Nym's is a modified implementation of a 3rd party invention.
• 4 - Community governance of the relay nodes - xx Network has had this for years and Polkadot has better governance features than Cosmos.
• 5 - Large anonymity set - xx Network currently uses 5 nodes and most messages generally delivered within 3 seconds (see Real Time (round) component in the xx Network dashboard - mean 24h latency is currently 2.12s). That seems enough for the use cases targeted by xx Network (chat, API proxy, voting, etc.), and can be increased. I don't know how large (it's not in the litepaper and I didn't try very hard to find that information elsewhere) Nym's anonymity sets are, so this advantage isn't quantified and doesn't appear significant for xx Network use cases.

Conclusion​

Nym has some advantages, but they're behind in terms of development - fully permissioned chain, no PQC and with legal challenges ahead of them.

VPNs are cool, but it's also just bulk traffic - porn, Torrents and crap of that nature. Not that we don't need that too, but it's a saturated and legally sensitive market (copyright violations, illegal content, etc). Due to the high cost of comparatively enormous bandwidth required for VPNs, it will be a very tough use case to monetize. And Nym Tech has bills to pay.

Dr. Chaum's decisions to not create a privacy coin and to focus on specific (and high-value) use cases such as messaging and voting were in hindsight perfect. The choice of blockchain platform (Polkadot/Substrate) - whether due to luck or wisdom or a combination of both - also seems better than Nym's Cosmos, so I expect less hurdles and faster progress with xx Network's Web3 integrations.

Personally I'm comfortable with design choices, target markets and other details of xx Network.

Nym looks like a decent platform, but they've made some less than ideal choices.