Home
Historically sensum was a project that explored the idea of anonymous users that communicate between themselves in a single thread or channel. Where they could only write messages (aka sensations) if an oracle choose them. And where those sensations were always broadcasted as push notifications to all the users that were part of the application (in other words, to all users that had the mobile app installed).
In order to achieved that, previous implementation required a middleman (a 3rd party server) that handle the app flow by:
- Act as random oracle that allow users to send message from time to time.
- Store the messages sent and serve them in to frontend mobile application.
- Send push notifications about new messages or elections.
- Store a (non disclosure) mobile id required to support push notification.
d-sensum is the open and decentralized version of sensum, that aims to allow broadcasting anonymous sensations through a decentralized network. This also means that no censorship should exist in terms of whom or what is been broadcasted.
- Broadcast messages (aka sensations) through the network.
- Anonymous users (aka souls).
- Decentralized network.
- No censorship.
- Open source project, open for collaborations.
- Sensation: A text message that is stored in a given smart contract (aka channel).
- Channel: Smart contract deployed by an Oracle that stored multiple sensations in a given network.
- Network: A Blockchain instance in self.
- Conjurer: Devops user that deployed channel contracts, or other kind of protocol related smart contracts.
- Soul: User that publish or request to transmit sensations.
- Ghost: User that reads sensations via a web client (a Graveyard),
Telegramgroup, a push notification, etc. - Sanctuary: UI that souls use to interact with the protocol
- Avatar: The Oracle’s mood tiny picture a Soul could choose as “reincarnation” to express their sensation.
- Messenger node: Server that aims to request mana to a given faucet and carry souls request to a given network channel.
- Herald node: Server in charge of notify/display sensations to ghosts that request to be notified about them.
- Graveyard: UI that ghosts use to feel sensations.
- Faucet: Blockchain faucet, provided by a 3rd party service.
In order to ensure better degrees of privacy in the protocol, it becomes necessary to provide ways of publishing sensations without compromising Souls identities or requesting their personal information. In order to achieve the aforementioned goal, we need to consider two main cases:
- Publish sensations using a Web3 Sanctuary without a Messenger Node.
- Publish sensations using an http Sanctuary with a Messenger Node.
To use a Web3 Sanctuary, Souls must first acquire mana. To do so, a wallet must be created and subsequently funded. Spending mana makes it possible to publish sensations through the execution of transactions in Channels (smart contracts) by configuring their respective network and address. In this approach, the only compromised information about the Soul ends being their wallet's address; which can be obfuscated or recreated as needed every time a new sensation wants to be published.
As far as the second case is concerned, to publish sensations, Souls do not need to use mana but rather trust in a Messenger Node. Honest Messenger Nodes should not store (or request) any personal information at all. In this case, only the Soul's IP Address is compromised; which can be mitigated by the use of VPNs or the Tor network.
Another key point of the protocol is to separate the process of publishing sensations from their consumption. Which means, it becomes essential not to associate Ghosts (users who can only read sensations) with Souls (users who publish sensations).
To achieve this, Heralds Nodes (servers that relay sensations to Graveyards using different communications formats) need to be independent entities, separate from Messenger Nodes (servers that publish sensations to Channels). It is then crucial for Heralds Nodes to avoid requesting sensitive information to Ghosts that could end up linking them with a Soul.
For example, a Herald Node working as a bot that posts new sensations on Telegram will allow Ghosts to join a group, effectively revealing their identities, but will not be able to associate anyone with the sensations they, as Souls, might publish.
Another example would be that of a Herald Node that allows Ghosts to receive push notifications for recently published sensations. For this process to work, it will require associating an id with the Ghost's phone or computer, somewhat revealing their identity. Since the Herald Node has no Messenger Node capabilities, Soul's identity won't be compromised either.
One of the main objectives is to deploy a PoC (proof of concept) of the protocol on a testnet. Doing so will imply that data will be eliminated at some point given the nature of testnets to be purged or destroyed over time. Although we could deploy smart contracts on the mainnet and achieve real persistence, using a testnet will provide us the opportunity to interact with the application without using real money at all.
Another approach to this goal would be to deploy the PoC on a private network. This would go against the decentralized nature of the project and the ideals of carrying it out. Nevertheless, anyone is free to implement it that way if they wish to.
Returning to the initial concept of deploying on a testnet, and addressing its main drawback: data volatility, we will undertake the commitment to design and implement the system in a way that allows for easy configuration of new Channels. This will enable a straightforward and uncomplicated transition to a descendant testnet (or a completely different one) in case of the current one getting destroyed.