PaulLeCam
commented
5 years ago 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
spm32
aquiladev
riusricardo
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 https://github.com/ethereum/EIPs/pull/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.