 My name is Louis Holbrook. I will talk to you about postal services over swarm I'm part of the jack team jack's company that's developing Decentralized marketplace for metadata in the media industry and Jack is building on swarm and we are heavy contributors to the development of a swarm Before I worked in jack though. I did a lot of different things. I was a classical pianist. I was Started and edited a cultural magazine. I was a music manager for a while funding bureaucrat and Also a taxi driver in Berlin for two years And while driving taxi one day. I picked up these guys and close bag They were totally star struck because they just met Snowden and they were blockchain people And I draw those somewhere. They told me about this bar that they've been in the Bitcoin bar I didn't even know they were existed one but half a year later. I tried it down there. I met this guy Victor and You know apart from all these things all my life I've been Involved in computers like most of you I presume and we got into talking about C-pointers and really really nerdy shit and Then he said look you have to see something so he sent me a bunch of these videos of you know swarm and and Saving the world from the clutches of these evil data analysts and stuff and I was sold so Then it started working and that's why I'm here in Cancun talking about PSS. So I'm very honored that Victor is trusted and trusted me the development of PSS I've been working on this for the last seven months and This talk will be try to explain what makes PSS tick it's internals But it's also an attempt to explain it in an easy to understand way so that you don't have to be a total nerd to To follow the narrative Be sure to also stick around for after my presentation because Up then are the guys from mainframe. They're actually built a chat app. That's running on PSS And that all of you guys can install and use today Now first of all, what is PSS? Well, then we have to ask ourselves what is swarm first of all By the way, a lot of the examples I'll be using here are going to be pretty contrived. So You know real world to the real world situation might not look exactly as easy as this But it's you know to try to make it clear So swarm is a network of nodes and Swarm is a network of nodes that makes it possible to store data without trusting the nodes that are storing it and Since the swarm network is rooted it always knows to short the distance from one node to another Now everything in swarm that stored on swarm is hacked into chunks and Every piece every of these chunks has an address assigned to it The address being the hash of the piece itself Now the chunk is stored at the node that has the most similar address to it and similar here means that They have as many bits as possible in the start to be the address Now the same logic is used when retrieving the chunks of course Since you always through this logic know Where to look for a particular chunk then there's no need for evil centralized tracking systems and stuff to guide your way In crude terms, this is what could them this rooting all about is finding the way to the data Just by the properties of the data itself Now PSS uses the same kind of logic But for sending messages So, you know messages is pretty much just content to write But instead of getting the address by hashing the message The sender actually just adds the address to the message manually Now this lets us send any content to any particular Location on the swarm network and that's exactly what messaging is of course To reach its destination messages are forwarded from node to node And everyone know that forwards compares the address on the message With the address of its respective peers and then forward the message to the peer that is closest to the message All the forwarding nodes compare the first part of the message to figure out where to send them But if we have less and risk information Then the address information we need that we have probably will match more than one node That means that by specifying less adverse information in the message We can define more than one node as the destination Of course we can also just choose to simply admit the address information and in this case the message is included at all Instead the message is sent by all peers to all peers This is of course not particularly efficient, but for certain scenarios it can be useful Whisper the existing dark messaging implementation on the Ethereum Uses this way to transport messages because it provides full darkness. There's no way of knowing You know where the messages are going just from looking at the traffic But of course it comes at a great cost When a message is sent in swarm all of the nodes that are forwarding the message Are also storing the message on swarm as a cache The hash of those messages is used To determine for example Whether this same message has been seen before Now as you can imagine from what previously has been explained if some nodes Wanted to just bomb the network with a bunch of messages, you know, that wouldn't be so hard. So therefore hard-coded into PSS is this Cache mechanism that is a crude accrued version of flood guarding if you will so Basically what that means is that When a message has been sent through and the message tries to send let's say a hundred thousand of exactly the same message Within one second or something They will already have the digest of the message they hash it again when they get it they see oh, this is the same thing So I will drop this since the messages pass Potentially pass through unknown nodes To get to where they're supposed to be They should be encrypted of course, so The nodes on the way can't snoop on the contents This means that the actual definition of a recipient in PSS is not the message Sorry is not the address of the node itself, but it's actually who can decrypt the message And this isn't necessarily only one node either If Warden more than one node could decrypt the message have the required keys Then those that group of nodes will be defined as the actual When we talk about rooting in swarm We talk about the notion of distances between nodes This can easily cause some confusion Because already mentioned swarm roots by how similar the addresses are to each other and nodes that are closer in swarm Could you know basically be totally different sides on the globe? So in measuring distance in swarm we should just forget about sorry forget about the notion of geography all together When we measure distance in swarm we put in the numeric amount on how many bits to addresses shares So if an old shares the first six bits of an eighth bit address, let's say Then the distance would be two and if five then Three and if just one bit then the distance would be seven This address that we're talking about this is swarm overlay address now This address here is not one byte long. It's actually 32 bytes long It's also randomly generated that is to say that it's impossible to infer from what information in the node this address is derived There are other notions of addresses in the theorem as well One of them is to p2p node address which is a combination of the tcp address of the node along with a private called node called the node key And PSS this is the address to use for step-by-step forwarding Furthermore, every PSS node has its own unique private and public key pair That it uses for encryption. This is currently the same public key as the account parameter is used when you invoke swarm Also PSS nodes might have any number of symmetric keys for encryption as well And these can be any arbitrary 32 byte value So how exactly does the process of forwarding work? Every swarm node has a hive and that's the definition of the collection of peers that it's directly connected to When you have a message that's to be forwarded you ask the hive About a list of peers that are closer to the message than the peer itself the node itself The hive will respond and the peer with the best matching address is contacted and passed the message and The same process has continued Now how can we make sure that the hive has enough peers so that the message actually can be sent to a closer address? For this there is the notion of health And to be healthy Every node has to have a certain amount of peers in various distances So first of all we define a Number of peers that it has to has is in closest neighborhood in this case. This is three This is what this we call the proxby now Here we see in the next step when we've done some connections that The peer has at least three peers and its closest Environment but that's not enough to be healthy in addition in Every increment of distances above this we have to have at least one peer So this is closer to the node. This is further away We have three in the closest neighborhood and we have at least one in the other bins That's a healthy node and now Since it's healthy, we can be sure that it can forward a message to anywhere in the network Now one of the attack vectors for spying powers is traffic analysis That's to say that if somebody can determine where the message stops Then they could deduce that that particular message was for that node and Therefore the closer we get to the node the message was addressed to Messages are forwarded to more than one peer and in fact that means that Messages are forwarded to all the peers in their proc spin their closest neighborhood and This is even done by the peer that actually is the intended recipient So it can decrypt the message, but it also passes it on so nobody can see where it stops So what does the PSS message look like? Every message has an address or not as we have seen before an expiry time a topic and an arbitrary bite blob That's the message itself Actually PSS uses whispers Envelope structure for anything but the address field and it uses whispers methods for encryption of the messages Encryption can be done using symmetric Cree encryption Or also public key encryption with the messages also signed by the sender one of the nice features whispers to able to The ability to pad messages that means that all messages are guaranteed to be a multiple of certain size Before encrypting the message is padded with random bytes up to this limit this threshold And it inserts also the first byte which is the number of Bites that constitute the signing Actually, there's nothing wrong with Embedding some secret information that padding itself as well And then you can have a harmless message where the message is expected to be and hide the spicy stuff where a spy may be And that won't look for them Now what's the advantages of padding well without padding all of messages will have different sizes and the very very skilled attacker could analyze this pattern and Order of messages and determine what the communication is all about When all the messages have the same size it makes that kind of attack less likely as we saw before a recipient of PSS is Defined as who can decrypt the message? That means as a sender we have to store the keys to keep track of our different recipients and Furthermore these keys may have one or more topic associated with them which in turn is linked to a swarm overlay address And keep in mind that it's fully possible also to have for one recipient to have multiple symmetric keys also Now what is this about topics topics are what defines what actions to take when you receive a message PSS has a registration method that links handler code to topics and in fact Even though this diagram doesn't show it you can register more than one handler function to each topic and they will all be executed When you receive a message with that topic When receiving a message using public key photography We can use the signature to determine which sender that is its public key the message came from So thus we know who to send back to when we want to reply and we might even have some address information on file for this peer We also inspect the topic and pull out the handling code or codes For the topic and that performs the actual action on the message What symmetric encryption is a little bit different because here there is no signature to inspect so We basically just go through all the keys until one fits this is of course not so efficient, but PSS has a caching mechanism also here so that the last used key Will be the first one that's tried and then the other ones are tried in chronological order with the logic being in that Whichever key you last communicated with maybe you know is more likely to have sent you the next next message PSS also offers a handshake module Which exchanges some ephemeral ephemeral symmetric keys using public key encryption for the exchange So when a handshake is initiated the initiating node sends a number of symmetric keys with an expiry count to the peer and Requests a number of keys in return The peer stores the keys it gets then it generates some keys and sends it back to the peer Why two collection of keys in PSS? It's implemented so that one set of the keys is used for outgoing messages and one is used for incoming So then when one message is sent using one of these keys The expiry count is decremented And when it reaches zero the key cannot be used anymore so the nodes to switch to different key and ideally also replenish the one that expired So PSS has an API that can be used through reached through RPC. That's Through sockets or through web sockets I'll go quickly through some of the methods here Not all of them. So to get the public key of the nodes the host node It's this function get public key Base address is to get the swarm overlay address of the host node To make a PSS topic There is a convenience function for this you send it a string you get a topic back a topic is actually just a four byte value And it can be any four byte value, but it's kind of defined to be The hash of the first four bytes of a has specific hash of this So this is what you get when you call this method To send the message you set using Public key cryptography you have to set the public key for a specific peer So you supply the key, of course you supply the topic and The address, you know, how much whatever you want to give or have of that And then it's just a matter of calling the send a sim function with the key with the topic and the message itself The message just being bytes, right? The symmetric key one looks a little different You have to in the same manner set the key the topic the address This is a Boolean that tells should this key be among the keys you attempt to use to attempt decryption So if you don't put it in there It won't be put in the pile of the keys that it goes through to match the incoming symmetric message If you do that at all now We use whisper for key handling and for symmetric keys whisper Gives you unique string ID That's a reference to the actual symmetric key in its back end. So the parameter here is a little bit different This is then the ID that you get back from this function So you have to use this when you send a symmetric message apart from that is the same as the ass symmetric one Now it's no fun to just talk right you want to somehow sometimes have feedback as well so to get the incoming messages you subscribe to to As you've subscribed through them through the socket and this is a pretty simple as a keyword Hardcore the keyword receive and also the topic for which you want to receive messages for If you're implementing this in Golang by the way, there is a slightly different syntax that you can use I Will defer explanation of this but it looks like this as far as hand shaking goes You have to activate hand shaking on each topic you remove handshakes from each topic to you can do that This is for initiating a handshake key topic and a couple of running out of time. So I'll cut it shorter and Get handshake keys which returns to all the valid handshake keys for a specific topic and a specific public key Now there's possible also to use PSSS transport mechanism for devP2P protocols you can use existing devP2P protocol code and Put it on top of PSS. Now this quickly turns a bit messy code-wise. So I didn't want to put it here But at least this is to prove that protocols are possible now a couple of caveats for PSS PSS is a little bit like UDP. You can't really guarantee that a message will get there Because the notion of connectivity is just It's opinion. It's opinion that it's actually connected to this. It also depends on you know the whole interlocking here So this needs to be handled in the application layer Also, since we are The closer you get to a node the more the message is passed around The end recipient might end up with more than one copy of the message now There is a small deduplication guard in in in PSS But we don't guarantee that deduplication will happen in all cases so mind that as well and of course as with anything a Cryptography there is absolutely no guard against stupidity, right? So I Mean it's it's not a magic solution. Don't send your key to someone or etc. etc for future development of so this is the feature set that's currently in in PSS now this will be part of PLC 3 and For further development on the roadmap is a mailboxing function Which we'll say how to store and tell nodes that are offline that a message came to them while they were offline We will look at multicasting capabilities. That is to say simplified routing when to several nodes when the nodes aren't necessarily in the same address neighborhood and also Using PSS to to modify states and nodes that can be used for for off-chain database updates and stuff So the until this is merged into master this will be the branch that you use for development In here is also a full documentation of the API with a few more functions that what I showed now there is also a peer-to-peer tutorial That shows a lot of basic step-by-step code examples when programming p2p in ethereum And that also includes a bunch of PSS code as well And lastly of course always happy to answer emails or join in on the chat on Gitter We're pretty much there all the time since we love computers and don't really have other lives That's it for me and there are 33 seconds for questions. Sorry about that You