20 posts tagged with "xx network"

DISCLAIMER: this is not investment advice. I've no idea what will happen and I don't recommend anything.

Introduction​

xx Network has been around for years and has users, but not very many because:

• many Web3 and coin projects suffer from Not Invented Here syndrome (example)
• many projects don't know about xx Network
• several smart projects know and appreciate xx Network but they're are still in the process of integrating with xx Network (or the other way around)

Worldcoin is one of those smart projects in "the other way around" situation - xx Network is creating integrations for Worldcoin and this is work in progress (and progressing well).

Specifically, there are three Worldcoin Foundation grants that were awarded to xx Network-affiliated developers. You can read or listen about it in this interesting interview with one of the developers.

Meanwhile, Worldcoin is doing their thing. Today I saw this:

MIMOS Berhad, the applied research and development arm of the Malaysian Government, has signed an MoU with the Worldcoin Foundation, Tools for Humanity (TFH) and MyEG, a leading e-government services provider, to integrate Worldcoin technology into the country’s digital infrastructure.

The intent of the MoU is to leverage the Worldcoin protocol and TFH technologies to improve ongoing and future work related to digital credentials. In doing so, it validates the importance of digital proof of humanness in the age of AI.

Hmm, wait, how many people live in Malaysia? 34 million.

Whoa - xx coin will go to the moon!!!

No, it won't. But fine - let's talk about postage!

Postage​

I've blogged about "postage", which is how xx Network plans to charge for its Premium tier suitable for power users.

Where will the collected postage go? Mostly to the validators - server operators on xx Network - and (if I recall correctly) part of it goes to the xx Foundation.

Does that mean that the price of xx coin will moon? Of course not.

We don't know if those Worldcoin apps in Malaysia will actually be released. It's just an MoU.

Even if they make it, we don't know if they'll choose to use Worldcoin's privacy features that rely on xx Network. The Malaysian integrators could choose to not use them at all and I'd say this may be the most likely outcome in this particular country.

We don't know how many apps will be developed, and how frequently they'll be used.

We also don't know if the apps will need access to Premium tier. Each individual user probably won't need it and postage measures access by each individual user. An app can have 5 million users and as long as each sends or receives several messages per minute, none of them will need to pay postage.

Are the chances of Worldcoin apps using xx Network's Premium tier nil, then?

Why pay postage​

While only a very small percentage of Worldcoin (or other platform's) users will require access to Premium (or "unlimited" aka "best effort") tier, anyone who charges for their application or service or wants to prevent another paying user (or all the free users) from hogging them out, may want to ask users to subscribe to the Premium tier if it's affordable enough.

I'm not making this up to spread the idea that massive demand for xx coin is inevitable or just around the corner.

What I'm saying is I expect postage will be inexpensive enough to be purchased for "just in case" situations.

When you think about it, that's almost the opposite from "xx coin will moon" - the idea here isn't to create scarcity and get rich off the appreciating xx coin. On the contrary!

The way markets work is: if you want more of something, you pay for it just enough to make the seller willing to satisfy that demand.

If xx Network's message mixing service (cMix) works well for you, there's no "reason" to pay anything. (But you have the option to donate to the Foundation if so inclined).

But the presence of a Free Tier also means that everyone gets the same rights.

Someone can stand up 500 containers in AWS and spam the network all day long just because. Or simply try to freeload as much as possible.

If this happens at scale, quality of service as experienced by Free tier users may be impacted.

If you are getting paid for the app you sell or rely on xx Network at scale, then it may be wise to avoid such congestions where a busy day for Free tier users translates into a busy day for your Support staff. It's better to pay some postage just in case of accidental or malicious congestions.

As users pay for Postage, decentralized nodes that participate on the network ("validators") earn more xx coins which means more nodes can come online without diluting any node's daily earnings and at the same time improves network throughput.

Demand for xx coin may result in its price going up, but I would not expect significant impacts from demand for postage because as long as similar services exist, no one will pay 3x premium for xx Network. They may pay a 10% or even 110% more, but not for very long.

In addition to this "just in case I need it" scenario, there may be high volume users who prefer to use Premium tier on a regular basis.

A power user who sends thousands of messages every day (example: IoT feed or remote camera that chunks images into many "text" messages) could set up multiple identities to stay within the Free tier limit, or make his life simpler and pay a small premium for 1-2 thousand messages above the cut-off message limit for the Premium tier.

How will postage work? You may view a draft of high-level design for v1.0 features here.

As you can see in that document, users will also be throttled per smaller units of time, so that no one can overload the network by exhausting their daily quota within 15 minutes.

We can also see that in v1.0 there will be no "reserved capacity" which some users would probably like to have. Examples:

• Elections: with 5 million voters and (only) 3 hours to vote, you may want to prepay for 600 messages per second during voting hours on the election day. xx Network would then lower its Free tier throughput from (let's say) 7 to 5 messages per client per minute and drop total Free tier throughput per second by 600 messages per second. But this isn't easy. We may need smart contracts (to reserve time) which Polkadot SDK has, but xx Network hasn't yet activated on its Substrate-based xx chain. And there's another problem: speculators could front-run legitimate buyers as election dates are known in advance and often hard-coded in legislative acts
• Any user with "guaranteed minimum" requirements. Even if you need to send just 1 message per minute (which well within the Free tier - there's 1,440 minutes in a day) - you may want to pay postage in order to able to send at least one message per minute

When you consider all these niche scenarios, it's easy to see how this gets complicated quickly. I've no idea what's the best way to go about it in Postage v2 or later, but for thousands of users with custom requirements, Smart Contracts maybe the way to go as all mixing nodes can easily look them up on xx chain.

Node operators and permissionless postage​

If you need guaranteed throughput for your clients, you can strike a deal whereby an operator gives you a dedicated, guaranteed fraction of their node's connections. You'd have to approach them on xx Network Discord and so on, but in theory that's possible.

No one needs to know, you get guaranteed throughput when everyone else may be timing out while connecting to xx Network gateways. Can that be done?

Not for very many messages and users, but it's certainly viable for either Free or Premium tiers. I can reserve 10kB/s for your client IP or throttle everyone else but your IP, for example.

Any node operator could make such side deals on their own for users who don't mind to always connect to the same gateways. That decreases user's privacy, so that's a trade-off which may or may not matter.

Another trade-off is if the network is overloaded, that node may be able to accept your messages just fine, but still unable to complete mixing them with other (random) groups of nodes out there, so it's not guaranteed to work in terms of actually sending messages.

I conclude this would be possible but not very valuable for either the node operators ("validators") or users. The Premium Tier is expected to be cheap enough to make these laborious workarounds unnecessary and unattractive financially, technically, and privacy-wise.

One use case for this may be local elections, where the government stands up 3-4 nodes and limits access to in-country IPs. As noted above that would impact - maybe even compromise (I'm not qualified to tell) - privacy, but not the integrity of messages (protected by PQC), but it would also make DDoS attacks on that day much harder to execute - any in-country IP addresses could be shut down in minutes, while foreign IP addresses wouldn't be allowed to connect to those gateway nodes. I can't estimate the impact of this approach so I wouldn't recommend it, but there may be similar use cases where having your own node on the network could be beneficial.

Final thoughts​

I don't expect Worldcoin's integrations in Malaysia will result in much demand on xx Network when postage becomes available. For Malaysia, I wouldn't be surprised if the government mandated that all Worldcoin-integrated apps include various gov-mandated data gathering add-ons.

But what excites me is that similar integrations will sooner or later happen in some other country. A Worldcoin-integrating app developer may also choose to enable xxNetwork-related privacy features. If that sounds unlikely to you, please see the interview with Mario and the voting integration (one of the three grants). Even Malaysia may want to enable anonymity in a Worldcoin voting app and disable it in other domestic Worldcoin applications.

Postage v1.0 may not be able to satisfy all use cases right away. DoS-style attacks by sock-puppet accounts could cause issues even to users of the Premium tier, but xx Network has world-class developers who are no doubt aware of all these things and will make recommendations related to privacy, security, performance and reliability expectations.

Postage v1.0 may become available a few months from now and it is one of the features essential for monetization of xx Network's mixing services.

Other apps rely on donations, subscriptions, or may be VC-backed and don't need to charge just yet.

xx Network is integrated with a blockchain service and very unique in that regard. Rewards - and later postage - are sent and received on a blockchain. For messaging, servers that pass and mix messages are operated by individuals from many countries and they're currently rewarded for their "mixing", but there's only a free tier so rewards aren't as impactful and demand for coins is lower because there aren't real life use cases for it. Postage will improve and better align users' and operators' incentives.

My take:

• Worldcoin in Malaysia won't make xx coin "go to the moon"
• Benefits of xx Network integrations with Worldcoin are real. Potential for adoption is real. When the first integrated implementation happens xx Network traffic could see a significant increase
• All other apps that use xx Network as "transport" could use Premium tier, but currently Worldcoin seems to be the most significant integration.
• Postage won't make xx Network expensive to use. It will make xx Network deliver more value
• Until there's a way to reserve throughput, apps with high reliability expectations should have a way to fallback to Tor or direct access when uptime is more precious than privacy

• Introduction
• CTIDH
• Why xx Network developers picked the vulnerable SIDH
• But, where is this xx Messenger?
• Timelines and additional sources (some of disinformation)
  • Signal CEO
  • techlore.tech
    • Techlore discussion forum tip
• xx chain scam, Signal phone numbers good
• Take-aways

Introduction​

I'm not a cryptography expert, so all I can do is rehash information from trusted sources (and you may verify it if you wish).

What value does rehashing content that I myself can't verify add? Usually not much (so I don't do it) but:

• This one improves discoverability
• It curates some information that I find valuable
• It can't post this where I should, so I am blogging about it here

CTIDH​

So the news - to me - is that xx Network client switched to CTIDH. I didn't know that until today.

[xx Network client] switched to CTIDH after a vulnerability was found for SIDH. Users interested in PQ messaging should use this branch.

Source: this commit

Where can people find easy-to-digest information about CTIDH? Go here.

What cryptographic primitives does xx Network client use? Current list from the edited page that still mentions SIDH s:

• XChaCha20: Length is 256 bits. Used for encrypting message payloads.
• Blake2b: Length is 256 bits. Used as part of key generation, key expansion, identity generation, and identification codes. Used to combine Diffie–Helman and SIDH keys after key integration.
• HMAC-SHA256: Length is 256 bits. Message HMACs.
• Diffie–Hellmen: Length is 3072 bits. Discrete log-based component of key negotiation.

Note that the page still mentions SIDH for PQ and below that is a note that it was replaced by CTIDH is below it. This is so that if you have a client with an older build, you know that you should use a newer client if you care about latest PQ encryption.

Why xx Network developers picked the vulnerable SIDH​

They didn't.

xx Network picked SIDH at the time it was not known to be vulnerable and they did it because it was evaluated and found to be suitable.

One reason particularly stands out to me because it alone - given that SIDH used to be recommended by experts in the field - made it very desirable for use in PQ private messaging.

the primary reason is the key sizes as they fit into a single packet

Source: xx Network forum

As you can see the SIDH vulnerability paper was published after xx Messenger was released.

You can read that entire thread for additional information and context, including this part:

This has no impact on the privacy of cMix.

But, where is this xx Messenger?​

It came out early and it used xx Network in a way that's not efficient by current xx Network standards (now the recommended way is xxDK).

As direction of development changed towards a less generic, more Web3-oriented applications, xx Messenger wasn't updated, but it was still considered not at risk and it wasn't promoted either. It would have needed total overhaul (front-end for Web3, back-end for xxDK) and while the source code is still available, the application itself was pulled (or allowed to expire, I'm not sure) on iOS. I haven't checked for Android.

Phoenixx.io has been developing a modern mobile-compatible client for cMix network. It's supposed to come out in H2 of 2024 and a beta desktop version has been available for a while.

Timelines and additional sources (some of disinformation)​

Again, for discoverability and curation, I want to share a few more links.

Signal CEO​

Signal was the first PQ messenger. That's according to Signal, as you can see in this piece of fake news by the Signal CEO:

• Source: Bleeping Computer

• Fact: xx Messenger came out in late January 2022

• Fact: SIDH key recovery attack paper received by publisher on July 30, 2022

January 25, 2022 10:30 AM Eastern Standard Time LOS ANGELES--(BUSINESS WIRE)--The world’s first quantum-resistant messaging app, xx messenger, launched on the xx network today.

The above is just FYI - don't mention this to any open-minded people like those who run Techlore.tech.

techlore.tech​

I've said at the top that I can't post a simple comment on CTIDH update where I'd like to. I meant I'd like to visit techlore.tech and share an update.

I'll use this post to say a few words about that community of independent thinkers.

Last February I head over there, register and, in a topic related to Wickr alternatives, mention two applications that use xx Network's cMix (not just xx Messenger):

• Speakeasy/Haven - as a modern (xxDK mentioned above) version but not yet for mobile
• xx Messenger - as a mobile app that (at the time) was still available on iOS

Since I'm following xx Network closely, I know that xx Messenger isn't maintained, I know why (for the reasons explained above), so I mention that Phoenixx.io plans to launch a modern mobile messenger and that Speakeasy may also become available for mobile.

But, in one comment I make a mistake and cite that false statement by the Signal CEO and also say that Signal has metadata that has been disclosed to law enforcement and assist in identifying users (not the content of Signal messages). A minor mistake - which I admitted and rephrased - was that I said that Signal had in the past disclosed users' IP addresses, but of course they wouldn't do that as law enforcement comes to them asking about the use of Signal (they likely already have users' IP address). I stick to the statement that metadata had been disclosed and that IP addresses could be as well.

Members and the owner respond with dismissive comments, insults, accusations and foul language.

Guy nicknamed TechFounder goes first:

Where’s their Post-Quantum encryption documentation? Has it been auditied (sic!)/proven it actually protects against those attacks?

Gee, indeed, where could it be possibly found? Maybe by searching the Internet for 'xx Network' or 'xx Messenger'?

You didn’t provide anything useful for anyone, just for your ego saying that your obscure messenger it’s better than Signal when it clearly isn’t.

I suspect that's what triggered them: I pointed out that the big news about Signal being the first with PQ was really a piece of fake news since xx Messenger (and possibly other) PQ messengers have been out there for a while. I did not claim xx Messenger was better at all.

She didn't say Signal was the first major PQ messenger and it wasn't on X/Twitter - her statement was posted on Mastodon - so she wasn't limited by the maximum number of characters per post so that she couldn't qualify her statement. To me, that's a problem and simply pointing that out ought to be useful to the community because it says something about the person who runs that shop. Not that she's compromised or anything that bad, but if you can't trust 100% of what a person says, it may be the time to start scrutinizing every word that comes out of their mouth.

One may say it's an innocent mistake despite not being limited by word count on X - one word less or more, what's the big deal? She's not a semi-literate, misspelling computer geek familiar with only computer languages. She knows better.

Whittaker completed her bachelor's degree in rhetoric at University of California, Berkeley

Or maybe she was indeed precise and accurately stated that Signal was the first to add PQ encryption to Signal. xx Network was the first to add it to xx Messenger. Everyone is right!!!

And what about TechFounder's obscurity comment? Of course, what can possibly be more obscure to people actively engaged in cryptography and privacy than work of Dr. Chaum?

But not everyone at Techlore.tech is incompetent and dismissive. Another user - Karner - obviously performed due diligence. Their expert opinion:

You’re referring to an obscure blockchain-based scam-based messaging platform that has no users and uses a broken cryptosystem (SIDH)…

All right, I'm promoting scams which I guess makes me a scammer (or a useful idiot at best). That's a promising line of attack against my claim that xx Messenger was PQ before Signal!

Never mind that I didn't even mention xx coin. But now that I am blogging on my personal blog everyone can check my X posts (tweets) and blog posts here and easily find dozens of occurrences where I encouraged and invited people to "invest" in xx coin and all the claims it's going to moon. Good luck with that!

Also never mind that although SIDH - one of the pieces in that stack - was found to be vulnerable, xx developers estimated cMix was still fine.

Then ThiccRaiden (claims to accept any pronouns in his/her/their profile - must be very nice, I thought) says to me:

You join the forum, literally make shit up and then backpedal to ‘well it’s hypothetically possible,’ while promoting a random messaging app

(The stuff I "made up" was the IP misstatement mentioned earlier, which I rephrased and which didn't impact the validity of my claim about Signal's access to that metadata - they may not retain it, but they do have it, as does AWS.)

I respond to ThiccRaiden's rude message by saying that I don't care about the rudeness, but I won't respond in kind and if the site owner moderates, they should apply the same rules to all members.

By now I've been called a scammer, poster of useless information (spammer?), and liar. What a hearty, warm welcome!

The site owner completely ignores all that and doubles down on ThiccRaiden's message of ignorance and FUD:

the Android App hasn’t been updated since August of 2022. Not touching this with a 50ft pole.

Let's unpack that:

• xx Messenger is obscure. False. It wasn't a Tier 1 - let's say it wasn't even Tier 2 - messaging application, but that doesn't matter. It was very likely the first PQ messenger, by early 2024 it was out there with PQ for years before other "alternatives to Wickr", cMix that it uses was created by some of the top people in the field and we know it wasn't obscure because the app had many downloads. Not only are/were there cMix messaging apps in ongoing development, but application interfaces are being implemented for "application messages" from other projects as well.

• Saying that Signal has users' identifiable metadata is "making shit up". Is that true? Yes. Signal operates Signal gateways. We know they have at least some MD on (date of user's last use).

Some may have seen this slide which says that Signal can provide "last date of a user's connectivity to the service".

• Saying that it's hypothetically possible is back-pedalling. It's not just "hypothetically" possible, it's simply "pending a search warrant". It's not even Signal that owns Signal gateway nodes - it's the freaking AWS!

If law enforcement delivers a search warrant to Signal, Signal gives what they have and law enforcement finds you used Signal yesterday. Then they also find that among 15 suspected friends of yours only one has also used Signal yesterday - how hard is it to guess which of the 15 may be the guy you used Signal to communicate with?

If Signal retains only "date" (no hour, no second), could AWS be asked to provide their firewall logs to help LE narrow that down a bit? Yes, but only theoretically, so don't worry about it!

Oh, no, they in fact do provide more than just a "date". Oops!

Millisecond precision. That's from here.

How about this scenario:

• LE asks Signal for a timestamp and gets it with millisecond precision
• LE asks AWS to give list of IPs accessing Signal gateways through AWS firewall during a 200 millisecond interval surrounding the timestamp provided by Signal

Is that only theoretical? How many IP addresses would AWS return? 50? How many from a small country? I'd say just one.

• xx Messenger hasn't been touched in a year. I know that, I know why, and that's why in my original message I said that and also gave links for Speakeasy/Haven and the Phoenixx app (at the time called Echoexx and available for alpha testing). But why not ignore all that and make a completely biased and ignorant comment (not that I care, but they purportedly do, being big on education and stuff).

• xx Messenger is vulnerable (I don't have the exact wording). When I mentioned xx Network's PQ encryption, they laser-focused on trashing xx Network because of SIDH and completely ignored that I showed that the Signal CEO in fact lied when she said they came up with PQ first, and that SIDH was not vulnerable when xx Messenger adopted it. Now that SIDH has been replaced CTIDH, I wanted to reflect on that thread.

• xx Messenger is a scam. This is hilarious. xx Messenger wasn't a blockchain-based app, it couldn't connect to any blockchain whatsoever, and even to this day xx Network's cMix is free for use. You don't need any coins, I even blogged about that here. But there's also a subtler, Signal-related point that I want to make at the bottom of this post.

Some of their comments are still online:

Nice people, right? Well, they say this about themselves:

We're a small team educating people

When you see "don't make shit up" in response to your civil and on-point comment, you know you're being educated!

It's a trap!

This is the owner's comment that followed (in which he didn't even comment on what I said about the unnecessarily abusive language in several earlier comments):

His vision (also from the About page):

We envision a world where technology works for us, not against us—and we want to prove to people they can make a real impact for themselves and others

That's very funny because I just recalled that, after the abuse that followed my comment on xx Network applications as possible alternatives to Wickr, I spent three hours creating (in the appropriate section) a post with xx Network resources, and answering questions from members who were interested in it. Making an impact, contributing, discussing with other knowledge-thirsty individuals, helping your fellow men better themselves - that's what it's all about, right?

And where's that topic?

Oh, it's nowhere!

They simply deleted my account, responses from the Wickr thread and all the content I'd created (even from the other generic topic), so it's all gone now. They also wiped my xx Network topic from archive.org. "We care a lot!"

Since only the quoted parts of my messages survive and they deleted all my responses while leaving their own comments and attacks online, I think it's perfectly appropriate to post about my Techlore experience here where they can't censor and delete me.

Techlore discussion forum tip​

Only ever make positive comments about Signal and don't double-down on them if you want to last.

That's my "lesson learned" from the short and miserable experience I had on that site.

I just checked on archive.org and found that penguin_terminal echoed my thoughts in this comment made in 2023:

I didn't think of this part:

your ISP reports you to the authorizes when logs show you accessing servers used by Signal.

Once your friendly government offices gets the "date" from Signal, they can ask the local telco or ISP for the hour, time and millisecond. Not that Signal already doesn't give that, but getting it locally is easier and they can get your phone number or fixed line subscription details in the same go. Nice!

Like me, he got "corrected" another Signal fan, Tech-Tropper:

This is absolutely theoretical and wrong.

Eh? Why? Here's why Session sucks (according to Tech-Tropper):

Besides, Session does not have PERFECT SECRECY. Just take your recovery code and login in with another device. You will see the messages sent in the last week.

It's simple - they "just take your recovery code". Scientists estimate that 94% of Session users have their recovery code on a yellow Post-it note on the side of their refrigerator.

One last thing about that Wickr thread and techlore.tech I want to say is about that "not touching this with a 50ft pole" by the site owner. Does this make any sense to you:

• The guy kept using Signal without PQ encryption (simply because Signal did not have any) for years. He presumably still uses it, despite Signal having his phone number, responds to warrants, while both Signal and AWS have access to his metadata
• But xx Messenger is a disaster because SIDH was found to be vulnerable. Never mind that there's no evidence that the app was exploited or even exploitable.

I don't know what's wrong with people on that site and I won't speculate about it.

I'm just happy that they deleted my account before I wasted too much time there.

xx chain scam, Signal phone numbers good​

I want to elaborate on that scam accusation and the parallels with Signal, as I said I'd do at the bottom of this post.

On Techlore forums they justify Signal's "need" for phone numbers as the only way to prevent spam.

Ugh, okay, but that's a "in order to save the village, we had to destroy it" kind of measure for a privacy-related application!

xx Network is still completely free and will introduce API limiting only for power users and only when postage becomes available, you don't need a phone number and you can use a network-native, decentralized identity. This has worked this way since 2022. Phoenixx also implements ENS-related identity (ENS).

xx Network is open to spam, that's true. If it was spammed, postage would probably be implemented sooner. But if you don't know a person's xx Network identity (which you can't unless they give it to you), there's no way to spam them in the first place so spam is still not a problem.

If you now consider just the privacy aspect here: which of these is a bigger honeypot and potential (privacy) scam here?

One app has your phone number and some metadata.

The other doesn't know anything about you, its gateways are decentralized in dozens of jurisdictions, there's nowhere to "register" your data and there's no plan for the average user to ever needing to pay anything.

I don't think either of the platforms is a "scam", but it's easy to see which one is designed for privacy and why having a coin users don't ever have to buy beats collecting phone numbers.

One of them is a major honeypot, that's for sure.

Take-aways​

• xx Network client now uses CTIDH
• Don't believe everything you read on Techlore

• How to include xx Network chat in your application
• What works and what doesn't
• Try it on Codepen
• Take-aways

How to include xx Network chat in your application​

This is a very simple test or "proof of concept", if you will, for the inclusion of xx Network chat in Web applications.

To minimize the amount of work required, I used iframes:

• The top frame shows a Web-based ImpressJS presentation
• The bottom frame shows xx Network Haven (formerly Speakeasy) app - event organizer is showing his view of a channel while using the community instance at https://haven.xx.network.

The chat participants don't login to Haven in this Web browser.

The bottom frame only shows chat from event participants, but both the top and bottom frame are just for viewing of organizer's content.

Any chat comment would be entered by each chat participant in their own xx Haven session (maybe another browser altogether).

Can guests comment and how?

The event organizer may share the invitation link and password in order to allow participants to comment from own Haven instance (accessed in the participant's browser), but that is optional.

We have several possible scenarios. For example:

• Only the event owner can chat (answer voice questions, share links...)
• Event owner and event guests (panelists, for example) chat, while guests can only view their comments in that iframe above
• If event guests are provided with the channel invite, they can login to xx Haven (own or public instance) and chat (ask questions, comment, etc.) as well

What works and what doesn't​

This is a very basic, no-code PoC, so it's not surprising that it's not usable in this form.

Production-worthy setup would require some customization of at least xx Haven CSS, if not the application itself.

But even so, we can appreciate and highlight some advantages and disadvantages.

The good:

• No email or other identity needs to be shared with the organizer, but panelists or viewers may choose to identify themselves by providing a signed proof of external identity
• Guests/panelists and possibly viewers receive the link - maybe it's shared in the presentation, maybe in another xx Haven channel - but links are not personalized and we can't know who is the author of each comment

The bad:

• Events open to public comments may be abused by spammers. Although individual accounts can be blocked by channel admin, automated spam attacks would be laborious to deal with so fully open events may be hard to manage
• Layout: obviously the xx Haven frame doesn't use space economically. We'd have to create an instance that only exposes the chat itself, and possibly put that "chat box" in a narrow, vertical frame to the right

xx Network currently retains messages for three weeks which may be both good and bad depending on use case.

Try it on Codepen​

You can try this on codepen.io.

First, switch the layout to have the code (HTML, CSS, JS) panes on the right hand side.

Then paste this code to HTML pane and wait for the sites to load.

<html>
  <div>
    <div>
<iframe src="https://impress.js.org/#/bored" width="1400" height="400">
  <p>Your browser does not support iframes.</p>
</iframe>
    </div>
    <div>
  <iframe src="https://haven.xx.network" width="1400" height="500">
  <p>Your browser does not support iframes.</p>
</iframe>
    </div>
  </div>
</html>

This screenshot shows a non-default layout (code on the right) with the iframes loaded/loading.

It may be tricky to login to xx Haven here, but it's easy to figure out once you realize you can scroll both left-right and up-down within the bottom frame.

Take-aways​

While this "integration" isn't even an integration - it's just two iframes - I think it does show the opportunity for using xx Network for events in which the identity of each chat participant can remain hidden and any comments cannot be linked to them even by the event organizer.

This runs contrary to the approach taken by most marketing-focused events - in the sense that participants' privacy decreases engagement and tracking - but for events where privacy of the commenter is important, there's no way to link a participant's IP address with comments.

A participant's IP address could be hidden by accessing the Web event address over Tor, but comments may be entered directly in participant's own instance of xx Haven which can even be running locally (e.g. in container).

Furthermore, xx Haven provides unique, reusable identities (bossCompartmentalisedDisownment in the first screenshot), so each network identity can be reused without disclosing the participant's IP address and/or true identity. This may be useful in situations where a participant wishes to be recognized - for example, a designated identity may be reused across events to provide support or engage in 1-on-1 chat with participants for follow up.

I've said it already so I'll just rephrase: it takes three PhDs to use SecureDrop - one admin, one journalist and one user.

But you don't know what you don't know, so instead of fixing the complicated mess that (current) SecureDrop is - which could be done by including any viable open source decentralized messenger into their packaged solution - they're coming up with a new protocol of their own. Of course.

What does it do?

What is implemented here is a small-scale, self-contained, anonymous message box, where anonymous parties (sources) can contact and receive replies from trusted parties (journalists).

Where's the server?

Server: For this project, a server might be a physical dedicated server housed in a trusted location, a physical server in an untrusted location, or a virtual server in a trusted or untrusted context. Besides the initial setup, all the connections to the server have to happen though the Tor Hidden Service Protocol.

Fine, I'll just set up my own Hidden Service.

But, does Source need a PhD?

Source(s): No on-device persistence shall be required for a source to interact with the system; they should be able to conduct all communications using only a single, theoretically-memorizable passphrase. The source uses Tor Browser to preserve their anonymity.

Just using Tor Browser properly is very hard. Haven users don't need to use Tor, but they may if they wish. Because with Haven, Tor is optional so it's much harder to use Tor incorrectly if either party does choose to use it for secure direct messaging.

I'd even say that modern messaging apps like xx Network's Haven almost cannot be used incorrectly. Choose a strong password and don't have a spyware infested browser or OS. That's basically it.

But this is SecureDrop, so here we go again... Start by subscribing to Udemy's "Python from Zero to Hero"...

# python3 source.py -h
usage: source.py [-h] [-p PASSPHRASE] -a {fetch,read,reply,submit,delete} [-i ID] [-m MESSAGE] [-f FILES [FILES ...]]

options:
  -h, --help            show this help message and exit
  -p PASSPHRASE, --passphrase PASSPHRASE
                        Source passphrase if returning
  -a {fetch,read,reply,submit,delete}, --action {fetch,read,reply,submit,delete}
                        Action to perform
  -i ID, --id ID        Message id
  -m MESSAGE, --message MESSAGE
                        Plaintext message content for submissions or replies
  -f FILES [FILES ...], --files FILES [FILES ...]
                        List of local files to submit

How it could be done​

Pull method​

In this approach Source shares files over a Tor Hidden Service and informs a Journalist to download the file.

This doesn't require any development.

• Journalist publishes their Haven nick (e.g. MrTriggerHappyJourno)
• Source runs owns Haven container or accesses other party's (e.g. public) Haven instance to create their own identity (DrDeepThroat)
• Source initiates chat with Journalist using Haven by contacting them directly and inviting them to personal chat channel with DrDeepThroat and MrTriggerHappyJourno as the only participants
• If the Source decides to share their files, they start Onion container with Hidden (Web) Service and share the link to the Journalist in Haven private chat

I provide a walk-through and sample configuration files below.

Push method​

This approach follows SecureDrop's approach where the "file upload" site is operated by Journalist. That seems like a very risky idea to me - Sources would better off uploading files to one of decentralized S3 services - but that's how SecureDrop does it.

In this approach they would still use a decentralized secure messenger (Haven from xx Network or some other) and the same Web server app Secure Drop already has.

Walk-through for Pull method​

I think it's easier to use Haven and Pull method than SecureDrop (Push method) and I'll show you why.

With Docker installed, the Source downloads this repository from Tor Browser or over SOCKS5 proxy (using git cli) and starts all the services they'll need.

git clone https://github.com/armchairancap/xx-haven-container
cd xx-haven-container/tor
docker compose up

Haven is now running on localhost (temporary VM) and Caddy provides HTTPS proxy at https://localhost:443 to Source. This takes care of secure messaging and metadata shredding.

If you want to know more, see this guide or fire up your own instance.

This list below shows all services in this Docker Compose.

The configuration files can be in line with best practices and thereby require zero configuration by either Source (they use Haven and Web server) or Journalist (they use own instance of Haven).

• Caddy - HTTPS proxy for Haven
• NGINX - Web server that runs my Tor Hidden (Web) Service
• Haven - local (personal) instance of Haven (to create Haven identity and chat with Journalist)
• Alpine/Tor - Tor server that exposes Hidden (Web) Service at a .onion address

$ docker ps -a
CONTAINER ID   IMAGE
52b873713f26   caddy                        
324711b42905   nginx:latest  
5e3054ec8d21   ghcr.io/armchairancap/haven:latest
023a0df1a5ed   alpine:latest 

Tor is running in Alpine and the Source can get our Hidden Service address from Container ID for alpine:latest like so:

$ docker exec -it 023a0df1a5ed cat /var/lib/tor/hidden_service/hostname
6x366z3rjmkx4ebtlpbq2hyoqng2yzy46zjtivydo4xovfj5xbk7zuid.onion
# alternatively
$ sudo cat tor-service/hostname

The hostname file is in the tor-service directory (relative to repo clone location: ./xx-haven-container/tor/tor-service/).

That's all it takes to visit the service on Tor - use Tor Browser to access that link.

But, what is our NGINX service sharing/serving?

The two test files I put in the tor-docs subdirectory in the place where I run docker compose up:

$ sudo ls  ./tor-docs/
file.txt  index.html

Actually, index.html isn't even necessary - it's there to make this demo simpler - by being able to view index.html which links to file.txt.

In any case, our Source shares 6x366z3rjmkx4ebtlpbq2hyoqng2yzy46zjtivydo4xovfj5xbk7zuid.onion with his Journalist and that's it.

The Journalist downloads the file over Tor and the Source can see that in Tor logs (in Docker Compose console).

After the Journalist confirms they got the file in Haven chat channel, the Source uses CTRL+C to stop Docker service and removes everything (the entire ./xx-haven-container/ directory or - even better - the entire temporary VM if they had one).

# press CTRL-C to stop docker-compose
# sudo rm -rf ./tor-*

With Tor identity removed, next time the Sources wishes to use the same stack they have a new Onion address while Haven identity could be restored if they backed it up (by exporting it from Haven Web UI to JSON file) and stored in a secure location.

Back to those file names: our Source could share a direct link to the file (6x366z3rjmkx4ebtlpbq2hyoqng2yzy46zjtivydo4xovfj5xbk7zuid.onion/file.txt) and file.txt could be encrypted if you wanted the extra security - the Source may share that password with the Journalist in their private Haven chat channel.

The password could be shared with the Journalist in Haven, but if the file is randomly named there's no risk of anyone guessing this file name on a Hidden Service address with directory listing disabled (it is disabled by default on NGINX).

To take that approach, remove index.html and move the content file to a random name:

# use CTRL+C to stop docker compose
$ openssl rand -hex 50
cd7457899fcd7ea28f09b8fd7eec090f9207634501ee910c3a58b3b7bb35e68e8ec17b05a7e1626059a089cd7318ec69589a
$ sudo rm ./tor-docs/index.html
$ sudo mv ./tor-docs/file.txt ./tor-docs/cd7457899fcd7ea28f09b8fd7eec090f9207634501ee910c3a58b3b7bb35e68e8ec17b05a7e1626059a089cd7318ec69589a
$ docker compose start

All that's necessary here is to put your content in ./tor-docs/. There's no configuration of any kind. For "production" purposes a project could further improve configuration files included, of course.

• caddy_config/ - auto-configured
• caddy_data/ - auto-configured
• Caddyfile - 3-line template file for reverse proxy on localhost, preconfigured
• docker-compose.yml - Docker Compose file, preconfigured
• tor-config/ - Tor Hidden Service configuration file (for NGINX), preconfigured
• tor-docs/ - file(s) shared over Hidden Service (file.txt, etc.)
• tor-service/ - Tor Hidden Service identity file (hostname, pub/priv key) - auto-generated if missing

Now, this isn't "more secure" than their latest PoC, but is it worse?

It took me two hours to put it together without writing any code and anyone who uses this is much less likely to make a mistake while using this approach.

Find my PoC configuration files here. (Credits: I used hidden-service-docker for Tor and NGINX.)

Summary​

SecureDrop wants to reinvent their own wheel despite the fact that there are several good decentralized, secure messengers.

Normally, secure drops start with secure messaging and they'd be better off if they simply picked one of existing options.

Once that's taken care of, file upload/download is no longer difficult when done on Onion network.

I wouldn't say these are "solved problems", but the point here isn't that xx Network's Haven "solved" the problem of secure messaging (maybe it did, maybe it didn't - see for yourself). It is that SecureDrop very likely can't solve it better than other decentralized messengers.

They ought to stop dreaming about their own "protocol" and do what they're supposed to do which is making it easy to share files in private.

• What does that mean?
• Impact on cryptocurrencies
• What can be done
• What xx Network has to offer
• Take-away

The Coin Telegraph reports:

Uniswap Labs founder Hayden Adams said its “ready to fight” after disclosing it received a notice of possible enforcement action from the SEC.

What does that mean?​

Let's soak in the wisdom of X for a minute.

(Presumed) teenage shitcoiner 1 on X:

No one that uses Uniswap cares about the SEC

The SEC doesn't care that no one who uses Uniswap doesn't care about the SEC.

All they need to do is to persuade Mr. Adams and fellow developers to pick another hobby (after they beat them in a Biden kangaroo court).

(Presumed) teenage shitcoiner 2 on X:

With Dexes like uniswap, SEC can bring down the domain but easily anyone can setup a Dex exchange like Uniswap.

Like anyone can setup and run a coin mixer - they can't, not for long anyway.

These SEC activities aren't unexpected.

It's happened before to ShapeShift which - curiously enough (see the link) - just settled with the SEC some five weeks ago.

The federal regulator instituted a cease-and-desist against ShapeShift, which dissolved its U.S. crypto exchange in 2021.

Very encouraging (for the SEC) - it took years, but now it's done!

One down, few more to go! Centralized or decentralized doesn't matter - as long as there's a person that can be sued, they're good to go after them. (In the case of the US government they don't even care if you're a US citizen or resident.)

Maybe some used to think - apparently, some on X still do to this day - that one can just ignore the delistings of their coins from CEX or the draconian anti-privacy and anti-liberty laws taking effect in EU and elsewhere.

Unfortunately, that's not possible as long as we have these quasi-capitalist and socialist governments unite in their fascist and globalist mission to eliminate freedom.

It's not hard to imagine what comes next - it's not unlike what I said in the post EU puts EU-based privacy coin users in untenable position. In fact, it's the same thing, in my opinion.

Here's how I see this will play out for DEXes:

• Prominent US-based DEX developers, non-profits, community members, server operators are silenced
• Many users drop off as well
• The same thing happens worldwide
• "Anonymous" (in their opinion) community members continue development and operations (decentralized Git, hidden services on Tor, etc.), but volumes are small and liquidity sucks
• Because anonymity and reputation don't mix well, scams increase (malicious commits, for example), fundraising becomes hard, and their user base a tiny fraction of what it used to be

Decentralized Exchanges won't disappear, but they're in for a very difficult period.

Another possibility - not immediate, but 3-5 years from now - is that the West sets up some version of the commie firewall that detects and blocks IP addresses of known DEX nodes. I know that's very difficult to do well, but so is today's blocking of general Internet in certain hellholes around world which does work very well. All it takes is a bit of disruption and a globally disruptive legal action which all major governments and globalist organizations seem to be eager to team up on.

Impact on cryptocurrencies​

It's easy to think this could mainly impact "illegal" (privacy) coins. That was my first thought, at least.

But that is not the case. It will impact all DEX users, all DEX exchanges and therefore all coins.

In the case of major crypto-currencies, any coin that other coins are denominated in - primarily stablecoins, but also BTC, ETH and others.

Who knows, maybe - in I'm right - privacy coins could regain some of the lost popularity among the leftover DeFi hardliners, but if you lose 90% of users and gain 20%, that's still not a great result and you're not growing or "changing the world" (sorry, that's as naive as I am willing to go - I won't say "democratizing finance").

I've just looked at the past 12 months of Ethereum vs. Monero on Google Trends. I assume the Google globalists aren't feeding us fake trends, although we can't exclude that possibility.

If you remove Ethereum from the chart and look at Monero alone, you'll see it went up a lot in late 2023 and then dropped off. I think it will drop even further (see that post on EU above).

But when Ethereum is added to the chart, Monero looks flat and barely registers.

It's not an apples-to-apples comparison, I know, but it shows two things:

• The average user cares about flipping coins, not about privacy (not something I like to see, but let's admit it)
• Despite the ongoing attack on privacy (and other) crypto-currencies in the EU, Monero is attracting just a small fraction of crypto-currency users, which I think confirms my expectation that most crypto-exchange users will give up or trade "legal and regulated coins" (completely useless circle-jerk as far as I'm concerned - it's no different from flipping FANGs all day long)

What can be done​

Maybe some "benevolent dictator" like that Bukele guy (not benevolent in my opinion, but I'm trying to think like the average teenage Bitcoin fan on X) permits DEX in their country and some prominent developers give up citizenship and relocate there, but this can't do anything for the users in countries where the use of decentralized exchanges is illegal.

Would economic and political gains from such policies be net-positive? Probably not. Maybe that'd earn sanctions, cut them off from the IMF/WB, etc. I'm not suggesting utilitarianism, but merely the fact that politicians have to consider it as there would be a price to pay.

Assuming some jurisdictions decide to harbor such activities, the next problem to consider is DEX users' privacy.

I wouldn't even attempt to suggest xx Network mixnet (cMixx) could be used to circumvent the problem. This solution already exists and works (see Proxxy) and we'll probably see it as an extension or "Web 3 app" in browsers like Carbon one day.

How many users will dare to violate laws this way? I'd say a small minority - primarily those from countries with governments "who haven't gotten their shit together" (yet).

Tor Browser may be another option, although it's not as good a solution as cMixx. It's harder to use correctly, and setting up malicious Tor nodes costs next to nothing. In fact it does cost nothing if you're a government and fund that activity with freshly printed money or new public debt.

What xx Network has to offer​

xx Network's Proxxy approach acts as a mixing proxy gateway between your client (for example, Carbon browser) and the server (for example, DEX server nodes). This is useful because it breaks the link between DEX activity (observable by all) and user's IP and location.

It also hides the connection between a wallet (addresses) and the owner. For non-private coins, a DEX observer would see there's a wallet with 123 XYZ coins, and monitor ins and outs, but they couldn't see who owns it. If one were to trade on a DEX via Proxxy, they could do that in privacy and exit to a privacy coin (so that the last leg is also anonymized on-chain).

But let's not forget that a DEX could route all its messages over xx Network's cMix protocol. xx Network dashboard currently shows 3000 messages per second. That could be enough for a DEX that doesn't attempt to provide near real-time settlement.

3000 messages per second is plenty, and can scale as soon as more nodes are added to the network (which is a function of network economics, but ultimately driven by demand which is currently a community decision and later may become a function of postage fees - more users, more nodes chasing their share of xx Network cMixx postage).

Take-away​

I'm not optimistic about this development now and the prospects for crypto-currencies in coming years.

Bitcoin is already a joke (see the recent news on how almost 50% of mined coins are routed to a single address - presumably almost 50% of "virgin coins" are bought by Wall Street custodians) and Ethereum isn't far behind (just wait until the first ETFs appear - it's going to be worse, because of staking which lets Wall Street farm virgin coins directly).

Crypto-enthusiasts think they (or "someone") can ignore what governments do "because decentralized". That works only until they knock on your door.

xx Network (Proxxy, etc.) can help and will help to some extent, but in a NWO environment it still can be stopped.

The only way this can be solved in the long term is by fighting centralization and that means civic engagement against globalists, dictators and autocrats - from the UN over governments of large political unions down to small countries.

Code is law, but not the law.

• Why it's good
• Why it's important
• What's not so good
• Scavengers welcome
• More to come
• Wrap-up

PatCrypt created a great post about the Wrapped XX coin aka WXX with the contract address 0x171120219d3223e008558654ec3254a0f206edb2 (view it on Etherscan).

Why it's good​

The main benefits are already called out by Pat:

• Compatibility with the major Decentralised Exchanges (DEXs)
• A shorter route to being listed by Centralised Exchanges (CEXs)

There's a lot to like about that, obviously, especially since:

• At least one CEX recently rejected xx coin because "it's a privacy coin" (except that it's not - I wrote about that here)
• The globalists have been making progress with their plan to "allow but disable" private cryptocurrencies
• Because of the KYC/AML regulations, listing a coin on a CEX has been expensive for years and now it's even worse - it's more expensive and more scrutinized

Because of that and because xx coin is not a pump-and-dump/meme coin (although anything that's tradeable has people who pump it, and xx coin is no exception), xx coin used to have a hard time getting listed. It's been listed on MEXC for some time, but that was about it.

I know some vocal MEXC users complain about MEXC (not in the context of xx coin, but in general), but considering it's located in a low-hassle country, I think it's a great exchange and all things considered, less likely to rat on its users than 90% of other CEX (all the EU-based CEX will have to rat on their users once they codify the latest EU regulations.)

In any case, WXX fixes "all of the above" (challenges): people will be able to get xx coin on centralized and decentralized markets (and anything in between - more on that later).

Of course, just being available on one popular DEX would be enough, but on-chain DEX are not known for great liquidity and they're (in my opinion anyway) less user-friendly and less liquid, although this last bit may change as more trading moves to DEX due to the fascist laws passed in communist and capitalist jurisdictions alike. We still want and need CEX exchanges, especially in crypto-friendly jurisdictions (go MEXC!).

Why it's important​

I haven't traded xx coin, or any coin for that matter, for many years. I haven't (yet) sold any xx coins either. When I have enough for my needs (which I now do), I prefer to do things that interest me - if I have free time I'd rather do something interesting and hopefully useful to the community than trade.

Why do I care, then?

Because WXX is good for things I care about, such as privacy and decentralization.

It is very important that xx coin be easy to trade because - see the post on new EU legislation linked above - xx Network plans to introduce postage (fees for prioritized and/or high volume users of its mixing network layer).

If you can't buy xx coin, you can't pay for postage (once the feature becomes available). That doesn't mean you wouldn't be able to use xx Network - its mixnet is now completely free to use and I have no reason to think it won't retain a generous free tier even when/if postage kicks in.

But I want xx Network to attract large users who pay postage, because that creates a virtuous circle: demand for xx coin to pay for mixnet postage creates a demand for coins earned (and sold) by mixnet runners ("validators"), which makes xx Network sustainable for both paid and free users.

This may seem trivial now (hey, it's free and it's working just fine as-is!), but remember this next time you use Signal and get that donation prompt upon starting the app.

What's not so good​

There isn't much not to like.

PatCrypt's posts mentions some admin to-do's and the fact that WXX is currently semi-centralized (which is what I mentioned "something in between" a CEX and DEX - even when traded on a DEX, it's still semi-centralized until EVM bridge comes about, which should be shortly).

A wrapped xx Coin was recently listed on the XRP Ledger (XRPL) where liquidity is thin and it appears there aren't many users. One may be reasonably skeptical about WXX as well, but I am optimistic because ERC20 tokens are everywhere. Anyone who owns more than two coins probably has an ERC20-compatible wallet or a CEX account and can easily access any DEX by simply installing an app. XRPL is accessible as well, but I feel its main user base are Ripple-focused users, which is fine but not as large as these new markets.

Scavengers welcome​

I won't put this under good or bad, it's something that simply is, and can't be judged.

An immediate effect of WXX is that its existence increases opportunities for trading, because the more markets which also means more opportunities for arbitrage.

With xx coin available on MEXC, XRPL, WXX (including DEX-es, each of which may be "out of sync" with others) and the fact that only MEXC has its own API while integrations for others already exist (for different ERC20 tokens, but it just takes a search-and-replace), it's no longer prohibitively expensive to build a bot that trades xx coins among several markets. It takes just one MEXC integration and a xx-focused repurposing of ERC20-compatible code for other markets.

It's kind of silly, but necessary. Scavengers exist because they need to exist. The main benefit for the regular buyer (or seller) is they get close to best price and liquidity regardless of where they buy (or sell) their coin.

Remember that, initially at least - until an Ethereum bridge is built and WXX decentralized - it may be inconvenient to easily move coins between MEXC, XRPL wrapped coin and WXX coin, but this will get easy for WXX once those to-do's are completed. For people who engage in arbitrage and move a lot of coins around this means arbitrage will remain inconvenient until that EVM bridge becomes available.

More to come​

Three things I'd like to mention here:

Firstly, Pat's article does mention Snowbridge, a trustless Polkadot bridge technology which - once completed - will bridge Substrate (Polkadot, initially) and Ethereum - something I've been looking forward to since last year.

Snowbridge is now getting attention in the xx community, but I think there still isn't enough appreciation for what had to happen in order to get here: the fact that xx Network picked a Substrate-based chain, which is the only reason why Snowbridge is now relevant to xx Network in the first place.

They could have picked some cooler "next gen" blockchain design with even faster finality and whatnot, but they decided to build on Substrate where all chains and parachains benefit from network effect.

Perhaps this isn't the best comparison, but Substrate can be compared to the Linux kernel. Once an improvement is implemented - due to permissive licensing - it becomes a new feature that every Linux application can use - all Substrate-based blockchains ("Linux applications") can easily benefit from it. That's why it will be relatively easy for xx chain to benefit from Snowbridge without spending many months on developing novel code just for your own project.

(This reminds me - even the development effort for a xx Network EVM bridge (that xx Foundation has awarded a grant for) probably significantly benefits from the ability to reference 3rd party EVM bridge implementations for Substrate chains. That's why that doesn't take quarters, but only months.)

So again, kudos to David Chaum and the team for making a good choice here. Maybe it wasn't a hard choice - naturally a decentralized mixnet project would pick a well-maintained and popular chain with governance features built-in, rather than a niche or new chain that requires a lot of in-house chain development - but it was still a choice and they chose wisely.

Secondly, due to network effects of the Substrate chain ecosystem, I think it won't take long for Polkadot to take advantage of Supra's HyperNova. Punchline:

In short, Supra verifies Ethereum’s L1 consensus cryptographically.

In other words (please visit that link to find out more), Supra's HyperNova does not need staked bridges that create multi-signature transactions.

The quoted part mentions Ethereum, obviously because that is likely to be the first target for Supra, but the same design applies to other L1 chains.

HyperNova is a new design and quarters may pass before it becomes available. But once it does, if Polkadot gets integrated, it becomes easy for xx Chain to get integrated as well. That means a Supra-wrapped xx coin could become instantly available on Supra in a decentralized, management-free and derisked (considering it's bridgeless) manner.

Thirdly, the benefits of Substrate flow in both directions. It is easy for other Substrate projects to connect with xx chain (not just for trading, but for on-chain identity, native assets held, balances, voting history, and other information xx chain holds). You can take a look at the Crust Network (based on a Substrate chain) documentation to see how they have a separate section for integration with Substrate-based chains, for example.

They recently released Ethereum integrations, but even in that case, it's nice to have a choice and be able to easily integrate semi-natively using the familiar Polkadot SDK. Ethereum bridges have many advantages (see WXX), but also adds a bit of complexity, risk, round-trip-time and cost. It's not the only answer.

xx Wallet was able to showcase native Crust Network integration by making their application code to load in one's xx wallet. I haven't looked if there are multi-coin wallets for Substrate and how they work, but they could make it easy to do buy xx coin for postage and use the purchased "message tokens" to pay for (xx) mixnet (proxied API) traffic created by Web 3 apps that work on other Substrate chains. It may take a year or two, but it's doable.

These are just three examples - there must be more - where Substrate (Polkadot SDK) can take care of 80% of the plumbing. It is much appreciated, but still widely underappreciated!

Wrap-up​

WXX makes xx coin available to all ERC20-capable wallets and markets.

This is a product of hard and smart work by xx Network developers (including the wise choice to use Polkadot SDK) and the wider Substrate and crypto community.

Also because of Substrate, the best is yet to come.

• an integration with Snowbridge could give xx coin a native and trustless xx-chain-to-Ethereum bridging
• Supra HyperNova - this would also require an xx chain-specific, but not unique, integration and would enable a direct, trustless and bridgeless xx-to-Supra cross-chain interoperability. I plan to keep an eye on HyperNova, especially if Substrate or Polkadot are mentioned
• DEX for native Substrate coins - useful for multi-currency Substrate wallets and shapeshift-like purchases of xx mixnet credits (to pay for postage)

Introduction​

xx Network is a privacy-focused, quantum-resistant "small messaging" network.

By "small messaging" I mean up to KB-sized messages, although it's possible to use larger messages as well. For example, xx Messenger supports small attachments (tens of KB).

xx CLI client is a reference client implementation for xx Network that at this time uses the older "broadcast module layer" approach.

Speakeasy (Haven) or Echoexx use a better approach (channels), but all of them use the xx Network SDK (xxDK).

xx CLI client repository has a read-me file that contains almost all the steps required to get started, but this post can still save you some time.

Build​

At this time we need go1.21, but check the source to verify if this requirement changed.

These steps are for Linux. Check the repository's read-me file for other OS.

git clone https://git.xx.network/elixxir/cli-client && cd cli-client/
go mod vendor && go mod tidy
GOOS=linux GOARCH=amd64 go build -ldflags '-w -s' -o xx-client main.go

Use xx CLI​

Let's see how to use xx CLI client.

First user​

Someone needs to create a broadcast (chat) first.

We can do that with --new, and give your broadcast a name and a description.

Setup procedure creates 2 files you need to know about:

• the first one is the broadcast definition file by default named $CHANNEL.xxchan (here, test.xxchan)
• the second is a private RSA key for the creator who is also channel admin. This one is by default named $CHANNEL-privateKey.pem (here, test-privateKey.pem).

export NICK="my-Name"
./xx-client broadcast --new -o test.xxchan -n "test" -d "Some desc"
./xx-client broadcast --load -o test.xxchan -u $NICK --waitTimeout 120s
./xx-client.linux64 broadcast --load -o test.xxchan -u $NICK --waitTimeout 120s
# in case of timeouts try logLevel 1 or 2 with: --logLevel 1

The default wait timeout value wasn't enough, so I extended it with --waitTimeout.

The reason is lately some xx Network gateway nodes had difficulties (potentially due to government interference in some countries) which makes it harder to connect. There's a log file which you can tail from another terminal to see that.

If you want to use a self-supplied RSA key, use --key ${FILENAME} to specify the RSA private key file, such as --key ~/.ssh/id_rsa_xxcli.

Second user​

The second user needs the broadcast definition file, as there's no way to establish chat without it.

The second user would normally have another nickname (although they're really identified by their private key) and needs to only load the channel, not create it.

Here we'll create the RSA key manually before we start (as we don't need to create a channel). This also means you can reuse existing RSA key if you have it.

export NICK="AnotherGuy"
ssh-keygen -t rsa -f AnotherGuyKeyfile
# move your new private key to the default private key file name for the chat "test"
mv AnotherGuyKeyfile test-privateKey.pem
# test.xxchan is the configuration file obtained from the first party
./xx-client.linux64 broadcast --load -o test.xxchan -u $NICK --waitTimeout 120s

And that is it!

There are minor console-related bugs, and you'll need to reconnect (simply CTRL+C and then restart) if you get disconnected.

Other details​

There are other details that you can find from online help, or by inspecting the code.

Available Commands:
  broadcast   Create or join broadcast channels.
  completion  Generate the autocompletion script for the specified shell
  generate    Generates version and dependency information for the binary.
  help        Help about any command
  version     Print the version and dependency information for the binary.

Flags:
  -c, --config string          Path to YAML file with custom configuration..
  -h, --help                   help for cli-client
  -v, --logLevel int           Verbosity level for log printing (2+ = Trace, 1 = Debug, 0 = Info).
  -l, --logPath string         File path to save log file to. (default "cli-client.log")
      --ndf string             Path to the network definition JSON file. By default, the prepacked NDF is used.
  -p, --password string        Password to the session file.
  -s, --session string         Sets the initial storage directory for client session data. (default "session")
      --waitTimeout duration   Duration to wait for messages to arrive. (default 15s)

Use cases​

xx CLI client cannot communicate with Speakeasy or Echoexx - as noted earlier, these use different module of xxDK.

But it can be useful on its own. Some examples:

• secure & private DM or group chat client for headless and remote systems without X Window System - like IRC, but with fewer features and more secure and private
• share IT-related secrets such as passwords and .env files with yourself or colleagues: load channel file, start the client, send or receive secrets and then delete the entire directory on the temporary client

A bit more on this last use case. You should use encrypted boot volume or change the secret if it's critical, as it's not technically possible to shred/wipe a single file on an unencrypted flash disk. For this use case you need to be able to get out to the Internet which is often, but not always (e.g. LAN) possible.

There are CLI scripts for "secure" password sharing, but they rely on personal infrastructure (some server & DB which may or may not be secure), or 3rd party infrastructure which may or may not be more secure than xx Network (and often doesn't have open source code on both the server and client).

There's also Tailscale, but again - to be equally secure, you still have to encrypt your data before sending it and probably at-rest as well (considering that the client is "online" at all times). If you can make use of Tailscale for other things that's great, but if you need something quick - like when setting up some VMs in the cloud - xx CLI client could be good enough.

xx CLI client could also be modified for other purposes, for example as a low censorship-free broadcast tool without the need for Tor (which mony networks block in any case). Access to the xx Network gateways can also be blocked, but most jurisdictions and corporate firewalls haven't done it yet.

As of now, xx Network gateways retain client side-encrypted data for 21 days, after which it expires and may be found only on the clients (if they logged in and downloaded it before it expired). So, keep in mind that you may shred the local session file, channel file and private key to disable access locally, while chat data stored on xx Network gateways expires in weeks. What you cannot delete is the messages other clients received on their side without access to those clients.

security.txt​

The Dutch Digital Trust Center mandates that all government sites must have a security files under the .well-known directory located at the root of Web site.

Use cases:

• Go-to place to get information on how to report vulnerabilities affecting the site or organization
• Improve the speed of getting in touch

Example​

https://www.ncsc.nl/.well-known/security.txt captured on Jun 1, 2023.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Domeinen van de Rijksoverheid kunnen met een 302 redirect verwijzen naar
# het centrale bestand op https://www.ncsc.nl/.well-known/security.txt
# omdat het NCSC het centrale meldpunt is voor kwetsbaarheden en incidenten
# voor de Rijksoverheid.
#
# Dutch central government domains can redirect to the central file located
# at https://www.ncsc.nl/.well-known/security.txt with a 302 redirect,
# because NCSC-NL is the central point of contact for vulnerabilities and
# incidents for the Dutch central government.

Expires: 2024-01-31T22:59:00.000Z
Canonical: https://www.ncsc.nl/.well-known/security.txt

Policy: https://www.ncsc.nl/contact/kwetsbaarheid-melden
Policy: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd

Contact: https://www.ncsc.nl/contact/kwetsbaarheid-melden
Contact: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
Contact: mailto:security@ncsc.nl
Encryption: https://www.ncsc.nl/contact/pgp-key
Preferred-Languages: nl, en

Acknowledgments: https://www.ncsc.nl/wall-of-fame
Hiring: https://www.werkenvoornederland.nl

-----BEGIN PGP SIGNATURE-----
Version: Encryption Desktop 10.4.2 (Build 1298)
Charset: utf-8

wsDVAwUBY+9c0P4Vd0fJc7lbAQpUmQwAwZ1vWyI1VKBChsciufRcvxy5zzMZMx6v
YjD5CXuDV4GL+tRl7wClnQO023e3ZChTH69y7O3veS+5/zNVUvpyqJfS8pNzG0pA
B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz192gWJvhxq8
mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0VZHfzF05Hr6NOoWvS6SRX
KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93AmYkP/sBWP4It3NpbiNuazc5iynhhih
+ZlfzsFV6agF4MZR0IQZ6X4jsCxKFrPIWW51/7W+PIDkqy6za/bDjDeiinid0HOC
2rro6N9FXSyxHz9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0rTcjUucaVikFJQ
wAls9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOjNgbmeQOlH4jnYWq
lNVMWzOncidAWM0nXcuYTjZagRAagthF
=yC4A
-----END PGP SIGNATURE-----

Use case for Haven​

• security.txt is PGP-signed to confirm that it was signed by the key owner and that's fine. But in reality most people hate to use it to compose emails or messages
• it is time-consuming for the recipient to download every sender's key which also delays reading encrypted messages
• Haven gives the reporter anonymity, both parties enjoy encryption and privacy, and can interact in real time (and still move to email if they so choose)
• Haven uses quantum-resistant encryption (I haven't checked, but it should be superior to PGP)

Haven public chat link can be added to security.txt. Example:

Chat: https://.............. (security vulnerabilities only)
Contact: email - mailto:.........; chat - send DM to `aCertainTestifier`
Encryption: https://www..../contact/pgp-key

Because public chat could have several permanently present strangers in it, direct messages (DM) should be sent to contact person.

What are the weaknesses of using Haven here?

The way I see it, the biggest is that xx Network keeps messages for 21 days and then they disappear. To prevent the situation where nothing happens for three weeks and messages disappear, the reporting person should move on to email if no response is received within hours.

With time, spam may become a problem for Haven. But it is already a problem for email now, so Haven is not worse.

Conclusion​

Haven uses xx Network to store encrypted messages and Haven users can connect to xx Network from any (trusted) application server - whether it's container on own desktop client, the official Haven instance, etc.

Compared to an email or Web service as means of communication, Haven is less likely to be affected by a vulnerability at the same time as your corporate email or Web service, so it is a cost-free, "out-of-band" solution that's more resistant to unplanned concurrent downtime or DDoS.

Haven gives you zero maintenance, quantum-resistant encryption, superior privacy (compared to email and PGP), and far more convenience.

Sign​

Go to Developer > Sign and Verify > Sign message

Pick an address ("wallet") to use and enter a message or other data you wish to sign with your wallet key to sign the following data.

This may be any text such as your Speakeasy codename, email address, etc.

Click on the copy icon to copy the signature (signature of supplied data) to clipboard.

Verify​

To verify, go to Verify signature rather than Sign and Verify.

Verify using address means the signer's wallet address (so, usually not your own).

You need to provide the same wallet and message that you got, and if everything checks out, the icon next to the supplied signature will become a green check mark.

Bad signatures will fail to verify.

Bad data will also fail to verify against a correct signature.

To be successful, verification requires the same wallet, message data and signature that were used to generate the signature.

Non-deterministic signatures​

xx Network uses Schnorrkel (sr25519) which doesn't create deterministic signatures.

For example, I created two additional signatures. Each time I got a valid, but different, signature to what I got in the first attempt.

• 0x2a40ed0.......3187
• 0xdec0ed9.......b78f

Containerized or non-containerized Haven​

It's probably easier to run Haven in a container. If you have Docker or Postman and want to run Haven in a container, try this.

In the case you want to self-host a non-containerized Haven, read on!

Home or cloud​

You may install Speakeasy at home or in the cloud.

Haven Web server doesn't hold any data but its OS and Node.js logs may store client IPs, that's all.

With that in mind, some high-level considerations would be:

• We don't want our Speakeasy Web app or underlying OS to get compromised
• If your Haven is not open to public, or is accessed "by invite" (maybe with basic authentication or VPN, for your family and friends), you may run it at home
• If your Haven is located in the cloud, that's acceptable as long as you can protect it from getting compromised so that application code doesn't get replaced, OS compromised, or visitors' IPs leaked.

Regarding this last point, if you feel comfortable hosting your Haven server in a small (1G RAM) VM, it is better to open it to public to have the Web server accessed by a variety of addresses. As long as you know how to protect the VM.

Software and hardware requirements​

Use a Linux OS or VM, x86_64 or ARM64 architecture. Haven's hardware requirements are minimal:

• 1 vCPU
• 1 GB RAM
• 3 GB disk

All Haven app/web server does is serve the app to the client(s) and that's one-time download from each client (around 100 MB download).

One vCPU is enough and won't be significantly utilized except when Node.js builds the application or when container image is updated - that takes a long time (15 minutes), but has to be done only when Haven code is updated or rebuilt.

Install Node.js​

On generic Linux OS, follow installation instructions for Node.js version 16.14 or above.

This post was prototyped on DietPi Linux, which currently uses Node.js 20. On DietPi, you may install Node.js as follows:

sudo dietpi-software install 9

Or, run dietpi-software, select Search software, search for Node.js, and proceed with installation.

Deploy and run Speakeasy​

We need to pick a directory for the application, clone the source to that directory, change some parameters and install.

sudo mkdir -p /usr/src/app/speakeasy/.next

If your username is joe, you could run it as such. Otherwise, create a non-sudoer account and use that.

sudo chown -R joe:joe /usr/src/app/speakeasy

That should allow you to run the rest without using sudo.

Next, clone the Haven source code, change configuration parameters and run it.

git clone https://git.xx.network/elixxir/speakeasy-web /usr/src/app/speakeasy
cd /usr/src/app/speakeasy

Pick Haven Web application port​

Most Node.js apps traditionally use port 3000, but you'll need something else if you have another app using that port.

Pick a port for Haven, such as 7080, and use it consistently later:

sed -i 's/next start/next start -p 7080/g' package.json
sed -i 's/const nextConfig = {/const nextConfig ={\\n  productionBrowserSourceMaps: true,/g' next.config.js
rm -rf node_modules && npm install -g npm@9.6.5 && npm install && npx next telemetry disable && npx next build

If that went well, you can try to start it from the same directory.

npm start

Check if Haven is up and running by going to http://${SERVER_IP}:7080. You may need to open OS firewall for that. Example for Ubuntu:

sudo ufw allow 7080/tcp

Since that port doesn't need to be exposed when Speakeasy is running behind HTTPS proxy, it is advisable to delete the rule after testing the application.

sudo ufw status numbered

You won't be able to do much with Speakeasy running at http://host:7080 because there's no reverse HTTPS proxy in front of Speakeasy. If you attempt to create an identity you will get stuck at the Find your Codename step.

Assuming the rules for 7080/tcp are number 7 and 8, and your HTTPS reverse proxy will run on the same host, you can delete the rules: sudo ufw delete 7 ; sudo ufw delete 8.

The right firewall port to open on the host would be whatever port is used by your HTTPS reverse proxy (e.g. 14443).

Reverse HTTPS proxy​

Deploy reverse HTTPS proxy in front of Speakeasy so that external port is forwarded to Speakeasy's application port (example: https://fqdn:14443 -> http://localhost:7080). To use 14443/tcp, open that firewall port on external network.

sudo ufw allow 14443/tcp

Now configure HTTPS reverse proxy to forward incoming 14443/tcp to 7080/tcp, and if you wish make HTTPS reverse proxy and Speakeasy Web app start (npm start) automatically.

For that you may use Caddy, Traefik, NGINX or other.

There are many ways to deploy each reverse proxy and at the same time there are no Speakeasy-specific steps here, so the details are an exercise for the reader. Find and try the official or community examples for your proxy and Node.js.

Custom port, host or path​

In the case Speakeasy is the only application proxied by HTTPS reverse proxy, it is most convenient to expose it at https://host:443.

In the case the same HTTPS reverse proxy is used for several applications, Speakeasy can be hosted in a directory (or, more complicated, at a dedicated virtual host name or FQDN).

TLS certificate​

In any and all cases, your reverse HTTPS proxy would need a TLS certificate.

If your reverse proxy integrates with Let's Encrypt, you could expose reverse proxy (and indirectly Speakeasy) to the Internet rather than use internal or even self-signed TLS certificate - it's more secure, especially if you additionally protect HTTPS proxy with firewall rules or basic (or other) authentication.

Haven Web server doesn't host any account or chat data. If you expose Speakeasy to the Internet, the main concern is to prevent NodeJS from application server take-over and tampering, so it can be advantageous to run it using a limited local account, and optionally add some form of authentication to your HTTPS proxy.

Once a TLS-enabled proxy is functional, you can access Haven, create a new codename or import existing, and start using Haven.

Update Haven​

As mentioned before, Haven can be simply wiped and re-installed because only serves the application code and does not store any client data.

The official instance (haven.xx.network) normally runs the latest version, so visit that site from time to time, or watch the Speakeasy repository for new releases, or follow xx Network on Twitter.