I was sent a donation in the amount of 77 EURMTL and asked for a review of the decentralized messenger Onym. Getting started.

The website onym.app explains the concept of the messenger. Its main idea is to eliminate the single point of failure and allow the user to choose the services that will be responsible for different components of information exchange.

The assumed structure of the product is roughly as follows.

1. The authors offer an open-source messenger client that is installed on users’ phones. Anyone wishing to do so can write their own client, and it will be able to operate within this same protocol.
2. Registering a new user does not require the input of any data; keys are generated on the user’s phone and tied to it. Since, however, anyone can write their own client, nothing prevents them from registering users even with full KYC, if they can figure out how to convince them to install specifically their client.
3. Data transfer occurs via Nostr relays. By default, the client uses a single relay supported by the project authors, but it can be replaced with one’s own or any public relay. A relay is a dumb transmission mechanism: it receives data encrypted with the user’s private key and puts it into open access, from where anyone who wants it can take it. Relays are not obligated to store user content for long, so ultimately all data is strictly tied to the end device on which the messenger client is installed.
4. The most unusual part of the architecture is related to group chats. Information about who is an administrator, who can invite new members, and who is part of the group in general is recorded in smart contracts on the Stellar blockchain. Thanks to this, group management does not depend on any single server. However, the end user does not need to worry about funds in their account for blockchain entries; this is done for them by a so-called relayer. The price of transactions in Stellar is pennies, but this is nevertheless a point of failure. An attacker could organize the registration of many fake accounts, creating a new identity in their client and immediately deleting it. The registration of each such identity would require a blockchain transaction, and the relayer would have to pay for it. Currently, the project operates on a test version of the blockchain, but upon moving to the mainnet, the expenses will become real.

The website also has an English-language page describing the threat model within which the messenger operates, and based on which the decision should be made regarding how safe it is to use. It is claimed that the messenger cannot withstand such obvious threats as a mole in the chat, device compromise, and physical coercion; such hypothetical threats as quantum hacking; and such resource-intensive threats as a biased Stellar validator or systems similar to the Russian SORM. The latter, however, only allow one to approach the disclosure of chat participants’ anonymity, but not the reading of messages within it.

Now a bit about personal impressions of working with the Onym messenger. This is an early alpha, meaning it is, of course, terribly raw, and a discount must be made for this, evaluating not so much the functionality that already exists, but that which is intended. The messenger allows creating groups, inviting an arbitrary number of people there, and communicating in these groups. In principle, many other Nostr clients can do the same, since such functionality is part of the protocol. But there, chats have some confusing semi-public status, and Onym, thanks to the additional Stellar layer, ensures chat privacy without using private relays. In general, this cute feature is intended to be the messenger’s killer feature: ordinary Nostr clients are not private enough, and private device-bound messengers like Briar require fully trusting the messenger client. Here, trust is distributed among several layers, in each of which one can choose a specific implementation, including one’s own.

As of today, the messenger looks like a simple proof of concept, and therefore, in essence, is aimed at IT specialists. For the average user, it looks a bit “bones out,” as they are offered setup instructions for Dockers and similar specialized matters in far too many places. I think that the main task for the authors of the idea today should be increasing the number of contributors in the project’s GitHub and generating interest among Nostr enthusiasts. Looking at the GitHub, it is clear that the project started in early May, then went quiet for a long time, and a few weeks ago the dust was blown off it and they continued hacking away. But if the project were to form even a small core of users who regularly sent their issues, the authors of the original idea would clearly have more motivation to work more briskly.

My recommendations to the messenger authors, in order of decreasing urgency:

1. Refine the minimal functionality that allows using the messenger: group administration (deleting users/messages), push notifications, demonstration of user statuses, at least a simple online/offline. It is essential to finish the claimed but currently unimplemented account export-import capability.
2. Get users used to a distributed architecture. The client should offer a list of independent relays and Blossom servers with monitoring of their status. As alternative relayers and smart contract implementations for group management appear, a similar choice should appear for them as well. Without the offer of third-party services, an unprepared user will be limited to default settings, and this will create a single point of failure.
3. Think about a desktop application and the possibility of simultaneously running the messenger from several devices. Tying the entire identity to the device rather than to the key will simply not allow the messenger to achieve any kind of mass adoption.
4. Implement audio and video calls; the Nostr protocol already allows providing such functionality.
5. Implement channel functionality, including a streaming function, which can also be realized via the Nostr protocol, while connecting Stellar smart contracts will allow one to avoid exposing oneself in the channel’s subscriber list.

The project has another website, opym.foundation, which describes the foundation that is intended to manage the infrastructure. The foundation’s website talks about why the foundation needs money and how it will be managed. The talk about money is devoid of calculations, and this strongly spoils the impression for potential investors. Moreover, the idea of a governing body somewhat contradicts the premise that every user should easily be able to launch their own service to handle that or another aspect of message exchange. It seems to me that the idea with the foundation should not take off, even if the concept of a Nostr messenger with Stellar contracts is warmly received by the public. Therefore, I do not plan to analyze the proposals for foundation management in detail, however, those who disagree with me can easily figure them out themselves on the foundation’s website.

Overall, the idea seems powerful to me, but in order for it to conquer the market, a great deal of effort will be required.