Louis Holbrook: PSS & Feeds, Dynamic data over Swarm | Swarm Orange Summit Madrid 2019

but you know but usually start you just start coding without any plan and then a couple of weeks passed and I realized I had to step back try to process some of the thoughts and experiences from that and try to coalesce into something presentable so right just some legal things first or a disclaimer so as I said this represents some current thinking here so this is not you know anything like proven or or anything like this its current thinking and by current thinking I mean some of my experiences of course all inspiration from from talking with Victor up the subject I'm talking of other team members a subject recent discussions with status on the subject etc and so forth and so forth a couple of other things I'm not going to talk about how you encrypt things or anything like this so the idea is to try to create a layer that's crypto agnostic and thus it does rely on the privacy guarantees that swarm has generally I'm not going to talk about insurance and persistence I'm not going to talk about identity discovery so how do you find out whatever what key represents a real person or anything like this it's just kind of current thinking hand-wavy stuff and yeah I'm not it so just to make it clear we are not sure it's just in current thinking yeah so I don't really have to show this because Xavier just went through this but what are feeds so basically it's have one persistent identifier that's always the same to point to data that as identifiers that's always changing so on the right side we have swarm hashes representing different updates of data on the left side we have the feed the feeds then comprises of short you know a short explanation some key that's signing the feet and some topic that's an arbitrary 32-byte entity so the basing building a basic building block of creating a chat and the most obvious thing that comes to mind is to create a linked list of swarm updates so basically the top one points to the next one points to the next one and so forth and then and then you use feeds to create the lookup point of the most recent one you find the recent one and you just follow the linked list down so I'm going to separate into one-to-one chats and multi-user chats so this is an example of a one-to-one chat what we see here is that they the first update they have they initialize the chat only just each site and then they post some messages some update to the chat on each of their feeds respective feeds now the feeds have for a he signs with his key a of course but the topic of the feed is B key B or some function of key B and B does the same thing using the topic for a as or sorry the key for a as the topic since we assume for the moment at least that they know each other's keys that's a predictable scheme of finding out how you can build a chat between two people clear so far good ok so what they then do is they pull each other's feeds for updates and using the time stamps on the messages they can merge these two feeds into time stream of messages that represents the chat and temporal space group chats are pretty much the same thing although so the basic principle is the same each participant keeps whips each participant keeps one feed with their individual updates each in each participant in the feed merges all those feeds from its participant in the chat merges all those feeds into a single stream of Jade's on their respective clients but the topic here is different they sign the feed with their own key of course but topic of the feed is the room name or some function of the room name for example so how do they know who is actually in this room to each message so let's assume that each of them keeps a list of all the participants in the room and then for every message that they post at the time of the message was posted they include a hash to that participant list in the message so now we can follow now we can follow at the temple space Hugh joins when and Hugh who were the recipients for for the different messages as time goes on so here for example we have a B and C being in the chat room initially they are linking all the messages to participant list with ABC and then mr. creosote over here joins a little bit later and when he joins then the participant list is updated and all the following messages are linked with that new participant list with the four participants so how does this joining somebody new work or I mean how can it work I'm not going to make any bold claims so let's say a over here is the responsible party in the group to add D to the chat or mr. creosote then he could issue for example an update with social system updates saying I want to move this chat to participant list too and then you see D and a initialize a news feed on this participant list too it's basically the same room with the same topic right but the future messages will now be linked to the new participant list the other guys could agree on this they issue their own move to prefer to participant to order and create an initialize update of their own and which case everything is hunky-dory actually this is yeah kind of a forking of the room in a sense right you can even make the forking even stronger by including the / - of the participant list in the topic of the room itself then it's very clear it's not even going to be the same feed they can of course reject it and say nope forget it I don't want this guy to join in which case creosote is understandably disappointed and a would return to back to the original chat or perhaps they just don't say anything implicitly timeout and then because the chat times out then they just assume that they don't want to add it so as I said the responsible party for joining would be B in this example so how will this protocol work well then a would ask B what is the participant list of this room B would answer BCD for example is the participant list and now he knows about C and D so he could check would see any catch equity of course and see if they match with each other if they do then it's hunky-dory if they don't 12 at least the majority might be right in this case so maybe he wants to trust the majority if the majority screws him over of course is understandably understandably and torched was it disappointed thank you again and solving this consensus issue is not going to be a part of so if it's not within the scope of this talk but but let's say there is some algorithm that or it would if we push that to the application level for example how to resolve these kind of consensus conflicts and hope that peace will and ensue so to recap a little bit for single user chats a needs to keep one feed to each of the participants BCD that means a signs the feeds and the topic is a function of their key and he needs to pull a feed from each of these participants where the topic is a function of his own public key for multi-user chats is a little different then a would only keep one feed for his updates to the room which are read by B C and D are the same feed but he has to pull and follow the feeds from B C and D is that clear so far you could like sorry yeah so it's kind of the same as this right but here the topic is the room right yeah oh you can ignore this at all it's not what you mean I see yeah yeah oh yeah so the only yes the only reason is that in this case you do not including a participant list so it is a very small obviously yeah basically you could do the same thing so it's just that in this case you don't really need it so that hash you wouldn't you know include it in the message maybe or something like that but yeah totally flexible sorry I didn't understand the question at first yeah so I started kind of in the middle of the story of how to describe the interchange of the messages themselves like when you're at it but how do you discover each other in the first place that's the question now I said that I was not going to talk about how to map real world identities to - I mean human identities to real world key identities but for the purpose of this talk we will assume that there is some public identifier key that a can know about if he wants to get in touch with be so phonebook or whatever right so that would be this is of course of course and closed to the world and everything a on the other hand would create a totally random key from lots of entropy so the idea is that a needs to transmit the ski to be somehow how we do this well there can be a contract of course on the blockchain where B listens for submissions - somebody wants to get in touch with you method call we can actually use PSS for this one example so either in the phonebook B can enclose the address and the key of the node that he's connected to - to receive this PSS message or we could or we could imagine that the PSS message is sent with fussy addressing or even as a broadcast even as a broadcast message kind of like a whisper message you can of course go the old-school way and do a USB stick or telegraph or something like that that's always an option a low-security kind of a low-security idea that i had the other day is to use a reverse feed in which you do a big no-no of creating your public key B creates his public key but also a temporary private key called B temp which I think I screwed up the letters here which a then can use to create one update in that temporary feed which contains the key his randomly generated key that of course can also be encrypted with these keys and nobody would see that key and but you know obviously this is not particularly secure but let's step back a little bit and think about secure what does it mean well there are different models around like the world is so it's a different story if NATO is out to get you then if you just want to dodge the big data AI harvesting of the fan group or if you just want to have a small band-aid for security right but let's face it that the threat that comes from natal and NSA and all of these isn't really relevant for most of us in day-to-day life I must say for my own part I must say for my own part I usually rent my apartment when I go away and I did this this time as well I was emailing with the guy and he wanted to have a copy of my passport understandably right because yeah some security when money changed his hands and she had a gmail account and I was figuring well I don't really want to send my passport to or a copy of my passport to Google not that it's distance I don't want to did to give AI the AI the the free scan of you know you know what right and I was thinking well what options do I really have here well so we could do the PGP thing of course but then he wasn't tech and actually tech people don't even do that because it's too complicated and then well telegram or whatsapp but then you know just the same kind of story you're in another way and then somebody's had signal but then you have the whole story but well he asked Lee has to install this app you know there's active thing that he has to perform and he has to tell her it was the phone and blah blah blah so maybe somebody has a better idea I was googling disposable chat to see if there is you know some way of actually doing this in the disposable way there was but they were all kind server-based so it's disposable untilled but it's on this herb right of some guy so let's just as a thought example let's see if we can use that latter insecure thing to outline a disposable chat so in this same manner here a generates the public key randomly generates this private disposable one-time update private key and sense this to be in my case it would be I sent him this in an email right at the same time some code is generated that we put on swarm that so basically what this looks like is that a would press a button and a link would come out that link would point to some JavaScript code that when run will generate it will generate a key for B which would be then fed to a using that temporary private key I don't even know if I and you know if I explain this very clearly but in this manner now using that disposable key both of them have their each their own public keys the only thing that really needed to exchange was this link to swarm and it happened magically and that's a disposable chat I could then send my passport and that was it so I was actually thinking about this would be even on the scope of the hackathon to do so if there's enough time maybe somebody would want to join with me to background with this so back to this so the key exchange thing so we of course want to try to avoid outside entities seeing or deducing what our identities are based on our keys well we want to keep our keys private right or so one layer the security is to hide the content another layer of the security is to hide who is actually talking to who and what kind of activity and I mean if they they know your keys and you know that they know that you belong to the keys that's a no-brainer right but if they just see some keys and they don't really know who's behind them but they can see what activity these keys have they can try to match them up by saying okay well when this guy has activity this guy has activity and might be able to deduce something so that might lead them to the IP address which might lead them to the person and that's of course a bad thing so out to thwart this well in the initial case here right we had the random key of a and we have a public key of B that public key of B is is known that's like a global identity so anybody knows that so what is the first thing they do when they establish to chat well a well B says Oh B generates a random key and says and this encrypted part of the chat that well let's move the chat to this pair of feeds using my new random key and then a could in the same old chat say exactly the same thing generate a new random key and then they he also moves to this pair of chat with that random key now from the outside of course this communication is encrypted with their with their public keys so the outside entity can't tell which address they moved to and that means that basically they could end up in any point of the address space of that are occupied by feeds so that's 20 bytes of user user address and theoretically you could for Eve each and every update you could even change this key if you wanted to if you accept the overhead and there's not necessarily that much overhead involved if it's possible in I don't think there is an API for this now but if you can insert an update in the feed without doing any kind of lookup of is there already an update and this feed but just place it like in the slot where it belongs in time then you could do this with it's quite not so much overhead right so speaking of overhead there is overhead involved in polling this feeds all the time especially if there's a lot of them so I mean this is particularly a problem with smartphones I would imagine what you can do is agree on some sort of max poll time space where you say for a certain period of time I know four or five seconds or whatever you would pull the other one if there was activity but then after that you stop and the contract is then that when he doesn't update again he will notify you with a pß message and then you start polling again for the same amount of time of course this also leads to certain privacy issues if you're worried about who's talking to who because now theoretically it could be possible to correlate if there is a pause in your communication and it starts again and that generates a notification and you can figure out where the pß message ends you can figure out the IP and etc etc and you're again so one way of perhaps one way of doing this even a little bit more concealed is is yeah Victor's idea about mail boxing so correct me if I got this wrong Victor but basically what I can do a can create a secret with she shares with B C and D and then he says that I want you guys can send a request to this mailbox node m to create an update which has the topic of this secret so M doesn't know this what this secret means B would basically just send the message to M give him some money and say can you please create an update with this topic and which points to for sample by public-key or some identifiers that a nose Maps bees public key what's the advantage to this while for 1m doesn't really have any way of knowing that a is the audience here so the recipient of this update is masked the other advantage of course as we can see that here a can pull the feed of this mailbox to see if there are in fact updates now from either B or C or D so it solves the same problem of the PSS notifications but without the perils of disclosing disclosing IP or location did I get it right Vic kind of oh great thumbs up I think that was it basically