PSS CHAT -- Swarm Demo App

[cobordism]

PSS Chat App

Context:

We are hosting several demo applications on Swarm including:

The Photocalbum https://swarm-gateways.net/bzz:/example.photoalbum.eth/
The ENS updater https://swarm-gateways.net/bzz:/swarm-ens.eth/
The Swarm File Manager https://swarm-gateways.net/bzz:/swarm-explorer.eth/
and more (see swarmapps.eth)

There are some new features of Swarm 0.3.x that we wish to showcase.

Goal 1: A simple demo chat dapp using Swarm PSS

Swarm 0.3.x contains the PSS communications protocol. It is documented here:

https://swarm-guide.readthedocs.io/en/latest/pss.html
https://swarm-guide.readthedocs.io/en/latest/apireference.html#pss

We would like a decentralised (Swarm hosted) application that leverages PSS messages for a simple chat application.
For goal 1, this application must allow a user to add another user's PSS address and then engage in a back-and-forth irc-style chat.

Bonus: Allow sharing of images
Adding an image to the chat, should perform an (encrypted?) swarm upload of the image and share the hash with the chat peers - so that they can download the images from swarm and inline them in the chats.

Goal 2: Named chat contacts

The Ethereum Name Service (ENS) allows us to have payment addresses and content hashes assigned to names. For example, theswarm.eth currently has d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 registered as the content hash and 0x3df7ce6b04663bb6f625bab474543d2e43aaaa44 as the payment address.

Under the hood, what the ENS does is to assign a special 'resolver' contract to the name. The currently used default resolver has fields for 'address' and 'content'.
See also: http://docs.ens.domains/en/latest/

There are discussions on changing the behaviour of the default resolver specifically to accomodate more diverse content hashes (such as IPFS multihash) alongside Swarm. (example: https://eips.ethereum.org/EIPS/eip-1062 or ethereum/EIPs#1577). In the medium term we would like to contribute Swarm related improvement suggestions to the ENS ourselves.

However, goal 2 of this project is simply to experiment with custom resolver contracts on the testnet. Try a resolver that allows users to add a PSS address to their ENS name and adapt the chat dapp to be able to find chat peers by name.

Be aware of the security imlications of forward vs backward lookups. [Nobody can stop me registering your PSS address at my name].

Goal 3: Feeds and Avatars

Another new feature in Swarm 0.3.x is that of feeds, allowing mutable content to be accessed at a static address.

Goal 3 is to experiment further by extending the ENS resolver and the chat dapp to enable users to create a profile (avatar, name, bio) that is updatable as a Swarm feed, and have the hash of that feed registered in the Resolver.

Bonus: use functionality from the swarm-ens.eth demo app to implement a "save profile" button in the chat app.

Bonus 2: Allow user-to-user payments to be initiated from the chat using the 'address' field of the resolver contracts as payment addresses.

[PaulLeCam]

We've been working on these problems for a few months at Mainframe so I have a few comments and questions.

Establishing contacts

With goal 1 using the peer's PSS address, would the assumption be that users have already shared their asymmetric or symmetric keys?
The way we've done this at Mainframe is to make all peers listen on a topic based on their own public key, that we call the "invite channel", and users need to share their public key with the peers they want to communicate with.
For Alice to send a message to Bob, the flow would be:

• Both Alice and Bob are online and listening on their own "invite channel".
• Alice has knowledge of Bob's public key out of band.
• Alice sends an "invite request" to Bob's invite channel using his public key and an empty address (0x). The invite request contains additional information about how they will communicate (for example, Alice's PSS address, a shared topic, symmetric key...).
• If Bob accepts the request, he sends an "invite response" to Alice, maybe containing his PSS address.
• Alice and Bob can now communicate over their shared channel.

The advantage of this approach is that only the public key of a peer needs to be known, and the "dark routing" preference can be set by both the sender and recipient, for example Alice can choose to share only a partial PSS address and Bob no address at all, so Alice's messages to Bob have to be sent with an empty address, and Bob messages to Alice have a wider reach than only Alice's node.

Here is a basic implementation of this flow: https://github.com/MainframeHQ/swarmchat

Encrypted images

AFAIK there is no HTTP API yet to encrypt uploads, only the CLI supports it?
That would probably be needed in order to support this use case without having to leverage an Electron wrapper for example to have access to the CLI.

Feeds

AFAIK currently updating feeds requires to use the CLI or sign the payload client-side before posting the HTTP request.
Using the CLI has the downside of likely needing a wrapper, and signing client-side requires the client to either have some access to the user's private key, or maybe leverage something like Metamask if it supports signing feeds? Any more information about what you'd expect the user experience to be please?

Thanks!

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 250.0 DAI (250.0 USD @ $1.0/DAI) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $37,872.41 more funded OSS Work available on the Gitcoin Issue Explorer

[spm32]

Hey @aquiladev you're good to go :)

[spm32]

Hey @riusricardo are you alright with being on standby here? Haven't heard back from @aquiladev yet and want to make sure we get started on this soon :)

[gitcoinbot]

@aquiladev Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[aquiladev]

@ceresstation @gitcoinbot I started the issue, it took time to prepare environment, forgot to comment the issue

[gitcoinbot]

@riusricardo Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[riusricardo]

@gitcoinbot Working on it.

[gitcoinbot]

@riusricardo Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[gitcoinbot]

@riusricardo Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[riusricardo]

@gitcoinbot Still working on it. I'll show the progress soon.
@aquiladev It seems that you are still working in parallel on this. I'll have a very fair time to work for the next 2 weeks. If you manage to make a lot of progress with your project, I would have no problem to give it to you. Anyhow I'll still work on it to create more demos.