Nym’s node families offer a pragmatic cryptographic solution to the Sybil attack problem by enforcing transparency among multi-node operators. This mechanism is a vital step in ensuring that decentralization remains a functional security feature rather than just a marketing buzzword.
Deep Dive
Voraussetzung
- Keine Daten verfügbar.
Nächste Schritte
- Keine Daten verfügbar.
Deep Dive
🛰️ Operator Town Hall: Node FamiliesIndiziert:
Nym node families just landed. They make routing more honest, rewards more fair, and NymVPN more private. Here's your chance to see how it all works! Node Families introduction by Claudia new UI walkthrough with Hꀎꊼ 🃟 naming conventions with Serinko roadmap update + mixnode stress testing with Mark S Bring your questions, we'd love your feedback! -------------- 🔒 NymVPN empowers you to enhance your anonymity online, overcome censorship, access content, and secure transactions. Try it free: https://nym.com/download Where to find Nym: https://nym.com https://forum.nym.com https://discord.gg/nym https://x.com/nym https://t.me/nymchan https://matrix.to/#/#nym-community:nymtech.chat 🎞️ Community calls playlist: https://www.youtube.com/playlist?list=PLoc3wV2YJYwpMUTCM9MPAwB2bWGhVMqCa
[music] [music] [music] [music] >> Welcome everyone uh to this week's not community call because uh if you're used to these community events and you haven't been around for a long time, then you probably haven't ever seen a Nym operator town hall. This is one of those very exciting times. There's a bunch of things happening on the operator front that we wanted to share with you guys. And for that, uh I have with me uh big chunk of the Nym team actually. So, I'll just go in the order of appearance on the screen. Um uh to my right there is Hux, aka Daniel, who's head of product. How's it going, Hux?
Also, Mark is back for another round, who's the CPO of uh Nym. How's it going, Mark? And of course, someone who you've if you've been around, you already know uh quite a bit, Claudia, who's a returning guest on these calls. How's it going, Claudia? Uh the chief scientist of Nym. And then of course, Jaya, another returning guest, uh our uh CSO, chief strategy officer.
And also, Serinko um from our devrel team.
Also returning guest. All right, so I've been uh sorry to say uh Ray because uh Ray was missing me. I miss you, too, but I've been sidelined for this. Uh so, basically, uh I'm just doing the intro.
Uh I'm going to pass the mic to Jaya in a second. Today, we're going to talk about something that has been brewing for quite some time um internally at Nym, which is uh node families, uh which is very exciting update both for node operators and also for the users of the Nym Nym network.
It's supposed to make everything uh significantly more secure. Uh so, we're going to learn about that today. And um a bunch of other info that comes with that as well. But without wasting any time, uh I'm going to pass the mic to I am but before that sorry I have to still mention that there's going to be a Q&A at the end as usual. So if you have any questions to any of the participants then make sure to sure to leave those in chat and we're going to pick them up at the end of the call.
All right, Jaya take it away.
Thanks so much Sudo and sorry for squatting your session.
But yeah, we the previous operator town halls have been on Jitsi but you know Sudo and style have put together such a fancy infrastructure for these sorts of calls.
So we we're hijacking it and we're using it for a little bit of communication out to our operator community. Today and also to the wider community. So maybe we can bring up the slides.
Yeah.
Yes, so operator town hall I think it's been you know quite a few months since we had the previous one. So we're a bit overdue a small update. The main focus of this operator town hall as Sudo said is however to introduce a kind of important technical update for our operator community.
And kind of give a little bit of an insight into how it's going to roll out and what that means if you're operating a node in the NIM network.
So this is what the kind of next hour or so is going to look like.
Um I'm going to do a just quick 3 minutes.
Then we're going to go through a little bit of a retrospective by Serinko on the evolution of the NIM operator community before we get to the technical nitty-gritty by Claudia.
And Mark is going to talk about the implementation of node families. And then we have a bit of a demo for you already which is exciting. Some UI's to kind of give a bit more meat to the bone on what node families actually look like and mean. In terms of implementing on from the operator side.
So quickly before I hand over to the rest of the team.
Um, thought it was worth kind of addressing first of all kind of elephant in the room.
Um, obviously we're going through a really rough patch um, in the team, in the community, in the operator community um, in terms of um, the performance of the token right now.
Um, that's something that we've been dealing with for a number of months already um, and it's kind of a little bit of a a symptom of a broader difficulties in in crypto markets, but um, in our case also you know, the more explicit consequences of um, some rogue investors that are dumping. Um, and kind of bigger picture what's uh, more of a kind of change of guard in our investor community um, so you know, we're working very hard in the background to bring in some new investors that really want to kind of help us take Nym to the next phase.
Um, and we're doing that at the same time as we're obviously, you know, plugging along uh, chugging along at our um, road map. So and just a quick kind of big picture look at where how far we've come so far this year. So this was the road map that we um, published beginning of the year.
Um, and you know, we've kind of completed a number of our milestones, which is really great.
Um, you know, we've got some wallet integration, some that are in progress, and Edge Wallet has obviously already come through. Um, and then we have some pretty major, you know, updates coming out in the next release of the Nym VPN.
Um, obviously we've seen Lewis protocol already being kickstarted with post-quantum keys coming out in the previous release. Um, and then we have, you know, a number of other um, really good uh, things coming up including um, advances in split tunneling and ad blocks. Um, so you know, in general we're making good progress on the road map. Um, and you know, we're hoping that the kind of technical improvements that we're making is going to um, also help you know, really pull the token uh, crisis out of its current kind of impasse um, and propel us into into the next phase.
So that's kind of a little bit big picture, but a reminder that, you know, we are working hard um on the technical side um and on uh you know, revamping the kind of investor group. Um and uh and that's all happening um in the background. So, I know we don't, you know, talk necessarily too much about that in the public, but um that's a bit the update here and um with that quick kind of big picture, I would like to hand over to Claudia who's going to get into the um uh node family scheme. No, sorry, we're going into Serinko first which we're going to talk a bit about um the evolution of our network um so far.
Serinko, over to you.
All right, thank you very much. Hey everyone again, it's great to be back in a town hall. Me and Jay have been talking about it for quite a while when we going to uh come finally back to to the community to bend share a bit about uh the things which I'm going to let for Claudia, Mark, and hugs and others.
But, I would like to come a little bit to uh talking about how our community, the technical community of operators been doing.
You've probably been watching the growth of nodes uh in your VPNs if you are user or generally in a network as operator operators tend to monitor the network a little bit closer.
And there's been also a shift into NIM improvement proposals where you had 11 proposals now being fully governed by uh the operators of of the nodes of the operators of the NIM network, right?
That changes the exit policy, the changes the governance uh generally the governance rules and how the protocol looks like is getting more and more into the hands of these operators.
But, what we don't talk about so much often and I would like to focus on a little bit touch upon today is the fact how there's been kind of organic professionalization of the technical community.
I've been having a this little you can look you can look in the explorer Spectra has nice decentralization tab and if you like just everything in a terminal I've been I wrote this little just like a script which returns me quickly the number of entities by the number of nodes they hold and control and how and how many countries they're distributed.
I've been actually surprised because there was a downside on some provider a few days ago and despite of that we've been having 23 entities in in them we usually call squads.
Sorry Serinko, I have to stop you for a second. It looks like for some reason our viewers can't see the slide deck. So let's fix that before moving forward.
So let's try maybe this. There is going to be a bit of delay. I switched views now ladies and gentlemen, can you please let us know in chat if you can now see the slide deck or no?
It looks like something broke in our setup.
If all else fails, we can share the presentation with you in the link.
Let's try a few other views and see if that fixes the issue.
No, still no.
Okay, how about if I switch back to this view and then bring the slides back up.
We'll try to re-upload the deck. This would only take a minute ladies and gents, just bear with us.
Sorry for the hiccup.
>> It works on my computer.
Works on my machine. Yeah, same here.
This never happened before by the way.
Slide Slide X always worked, so it's very strange. Never saw this behavior before.
Just one second while we'll uh getting the the deck and uploading it.
And until then you can look at us in our full beauty. How do you like my background, Serenko?
It's nice. It's a little bit more realistic than mine, but you know, it's different taste. Way more real.
Way more real.
No, but yours is actually nice, too.
I've been seeing some uploads there.
Let's see what's going to happen.
Yes.
See if this was already added to the slides. Uh All right. Now it's been re-uploaded.
Let us know, ladies and gentlemen, if you can see it. We're going to wait for your responses in chat.
There's a bit of delay by the way between chat and um and the live stream, so that's why.
No, still the same.
Okay. Well, in that case, we will probably have to share the deck with you, and you will have to follow along. Sorry, ladies and gents, we were not prepared for this.
This never happened before.
That's the very description of errors, right? Yes, exactly.
So, let me open up this deck.
>> [snorts] >> Or, actually, Hucks is saying something good for once, which is to share my screen.
That will definitely work.
All right, share screen.
Yes, here we go.
Going forward, please say next slide when you want to when you want to move slides, and hopefully this will work. Apologies for the interlude, everyone.
You can probably go full screen, but all right, let's go. Where had we been?
I'll go straight real quickly.
Chat also came through. Hello, chat. Oh, yeah.
Well, I was just going to say I I'm guessing a lot of the things I was saying didn't make much sense if people couldn't see the road map slide that I was showing.
Um anyway, maybe we can share some of this with the community afterwards. We can share the deck.
So, back to what I wanted to point out is that the community's been organically professionalizing itself and going into entities, which we usually call squads.
Be that whatever type of entities, DAOs, collectives, bunch of friends, or professional kind of like company running nodes together.
So, when I run that through the little code I sent you, I came to a little surprise because despite having a little bit downside due to one provider uh falling down, I came to realization that if I look on entities having five and more nodes uh controlling, this is uh sorted according to host name.
Uh provided that that's the people who's got the, you know, the access to the register.
There's 23 of them. So, there's 23 squads running five and more nodes in a network, which is 47% of the entire network. So, this is just kind of like a pre-amp to what we're going to be talking about because that dynamic has been already existing. Uh next slide, please. People have been kind of like naturally figuring out that there are advantages running these things in coordinated uh group, in coordinated collective or organization.
They organize their work uh to have bigger efficient effectivity and efficiency, right? That you can distribute between your members the tasks. Maybe somebody is taking care of uh more of documentation, somebody is doing the administration of the landing pages, uh the nice graphics, or something. Uh somebody communicates uh in in the in the forum, so you don't have to be all at the same place.
There is also greater knowledge base sharing. You can guide each other, you can grow together, uh you can guide and response to the new operators. Can be great example, which is happening in the community all as well. But furthermore, if you got a squad, uh you got entity which holds bigger stake of a network, uh but especially if more of those is not centralized, there is growing reputation.
And all of you who've been around in this competitive environment, it's pretty difficult to make trusted brand for whatever you're doing.
Uh incomparably how easy it is uh to lose that.
And last but not least, next slide, please, is the scaling.
As the network is growing, some periods are like, "Why wouldn't we run more nodes?" But eventually it becomes it takes some time. And if I want to run 10 times more nodes, it going to take me 10 times more time if I would be linear on like a linear scale logic of thinking.
Therefore, we started to to get ready operators be looking a lot into what scaling means. How the leveling up the game would look like, right? And there is two major points which people been already doing, and that's virtualization of their own nodes uh sorry, of their own servers. So, people would buy dedicated server or even bare metal and virtualize it themselves, uh which we have documentation for. I'm going to paste the link here.
Yeah, the publish it, please.
Um that increase your ownership, tweaks, and all the adjustment of the server uh and which complete control in your hands.
But it's more cost-efficient when it comes to a dollar per bandwidth and per uh memory and what have you. And secondly, the orchestration by Ansible.
And that's something I just want like everyone to really look into if you're running three or five and more nodes.
Maybe let's take five as the reference since I started number. Um it is bit of a steep learning curve in the beginning, but then you realize you have this one tool which rules overall, right? You have your node and server state is in consistent uh it has a consistent state across all the servers you have, especially if you use the same system and everything.
And you deploy, you upgrade, you bond, or you mitigate some vulnerabilities, what have you, everything through one command. You simply run a command Ansible playbook, run a Playbook, or point to a subset of nodes, or just use a particular tag, and hurray, there you go.
Uh so, this is kind of just like a a little intro to say how we got now without even thinking uh of what Claudia market hacks is going to be talking about right now to kind of put it in a little perspective, because this is already kind of a place where we arrived due to like a natural exploration and a growth of a network from a few nodes, which it's been few years ago to 750 nodes, which the network uh looks like now.
I'm passing to Claudia, I believe, with that one. Sorry, I thought it was a given.
Hi everyone. So, next slide.
Yeah, so I'll be talking a little bit about the the how we are we're going to address uh people running multiple nodes with node family declarations.
Uh so, yeah, next slide.
Yeah, so I mean, the the core value proposition of of uh Nym is basically decentralization.
And uh the idea is that network privacy is provided basically by routing the traffic through multiple independent intermediaries, right? In the case of the WireGuard mode, this is the entry and exit, so two entities.
>> [snorts] >> In the case of the mixnet mode, this is um five entities, because there is like the three layers of mix nodes between the entry and the exit, as you see in the in the in the picture top.
And the idea is that because you have your your communication is going through all these different intermediaries, no single intermediary is able to see the full path from source to destination, and therefore find out who is talking to whom, so joining the source and destination of a communication.
Now, if all the if you have multiple intermediaries, but all these intermediaries are controlled by the same operator, or maybe they are not controlled by the same operator, but they are visible towards the same local adversary, then these benefits of decentralization are lost in the sense that you have you basically revert to what would be like a centralized VPN, where you have like one intermediary, even though it's multiple, it's logically one because it's the same entity controlling all of them, right?
So, then that would negate the the benefits of decentralization and reduce the security of the routing to a centralized VPN. And I I want to emphasize routing because there's many other features of the Nym network that would still provide additional protection compared to a normal centralized VPN, namely the ZK-nyms and the fact that it's unlinkable, the usage over multiple sessions, that the payment is unlinkable to the usage, and all of that. All of that would remain, but the the kind of source-destination linkage would no longer require collusion because you have only one entity in the as as is the case for a centralized VPN.
So, next slide, please.
So, yeah. So, currently, even though there are many as Serinko just mentioned, there are many squads or people that are running more than one node.
This is currently not in This is currently not taken into account when when choosing nodes, right?
So, people who run multiple nodes often give them names that are recognizable as being part of the same family. So, they would have like the name structure of the node would be such that you you could understand that this is the same operator or probably the same operator.
Um So, you can actually already just with those names, you could you could actually already avoid choosing nodes from the same operator. Uh, however, if you choose nodes manually from the same operator, you would receive no warning, they would just connect to them. And when you're selecting countries, the app might actually pick, uh, from the countries you have selected, nodes that happen to be from the same operator, because this is nowhere at the moment encoded in the system, right?
Um, so, uh, this is this is not great, because when the operator has both the entry and the exit, uh, they have visibility over the full route, uh, particularly in and the the two-hop mode, uh, which is the one that is mostly used. Um, and that would enable this operator to join source and destination, they have the full path, so you don't have the benefit of decentralization. And it's not only bad in the sense of it's bad for the operator for bad for the user with respect to a malicious operator, but it's also bad for the operator, because if you are if you have the full route from source to destination, you can also be compelled to provide this information. So, you you don't want to be in a position where you you have this information, because this information might make you a target as well. So, you want to not be able to have full full destina- full path, just like one piece that is kind of meaningless unless you you join in with others with others.
>> [snorts] >> In addition to that, uh, different operators sometimes, uh, put their nodes in the same hosting provider.
Uh, so that means that, uh, single hosting provider in two-hop mode would be able to see kind of the source connecting to a node in the hosting provider, an internal connection within the same hosting provider, and then going out to destination. That would also give this, uh, hosting provider kind of visibility over what are the likely, um, input-output connections end-to-end. So, that's also not not great.
Next slide.
So, what can we do to solve this? So, the the the proposal is to introduce formalized, uh, node family declarations.
So, a node family is basically a set of nodes that are is run by the same operator. The same could be the same person, it could be the same collective of people that are working together, some organization.
This is controlled by a family key, so there will be some cryptographic key that is kind of controlling family membership.
And this provides some guarantees. So, for example, no fake family members.
Right now, I could run a node, call it expected now, and pretend that it's one of the nodes from expected now, even though it's not, right? So, for example, if there's an operator with high high reputation that everybody trusts, someone can just launch no nodes that look like they are from the same family, but they are not.
Once we have these families controlled by a cryptographic key, this would not be possible. You will not be able to claim fake family members unless you're really from the family. And then you have when two nodes are certified as being from the same family, this is this is kind of cryptographically linked in the sense that you can be sure that these nodes are really controlled by the same person.
Now, when two nodes are in different families, this is not an absolute guarantee that of independence because it could be that they are controlled by the same operator, and this operator did not declare the family. So, we we don't have 100% assurance on that.
But we do have assurance that if they are from the same family, they are indeed controlled by the same operator.
In terms of colocation, we define two nodes as being collocated when they are running in the same hosting provider ASN, meaning that they are sharing the same infrastructure.
Next slide.
Thanks.
>> [snorts] >> So, once we have this this kind of colocation, which is already available in the node descriptors, the information that is needed, and also these families that are being added, then we can have exclusion rules when choosing a an entry and exit gateway, right?
So, there there's two basic rules. The entry and exit of a single connection must not belong to the same family, okay? So, they must if if if if your entry belongs to a family, you you should not pick an exit from the same family. You should pick an exit from a different family.
And entry and exit gateways of a connection should also not be co-located. That means that they should be in different physical locations, different hosting providers, so that there is no single hosting provider that has visibility over the full path.
Okay?
So, these rules the idea is that the rules would be respected always in automatic gateway selection. So, when you select a country, the the app will never select entry and exit that are from the same operator, same family, or the same hosting provider, same co-located.
>> [snorts] >> Um when people are choosing manually, it would still be possible to override um because maybe somebody has a very good reason why they want to choose the same operator. Maybe they know these operators personally and they really trust them, or maybe they want to test something, or maybe they want to use the same hosting provider to really minimize latency so that there is almost no propagation latency between entry and exit. People have might have their own reasons. So, manual override is possible, but of course after a clear warning that this is kind of a doing away with the central with the decentralization properties that you would otherwise have.
And this applies to both fast and anonymous modes.
So, next slide, please.
Do Did we solve all the problems? No, we have we have significantly with this we basically achieve that all these operators that are currently in the network with multiple nodes, they will, you know, by by having these family declarations, they will never again be chosen as part of the same connection. So, that's reducing the the increasing decentralization, guaranteeing decentralization assuming that everybody is playing by the rules, but of course you could have malicious operators. This is the residual risk that do not declare all their nodes as a family. Maybe they are running five nodes and they declare all of the five nodes are independent or they say, "All these four are from the family and the fifth one they they don't say that is from the family, right?" So, this is this this is still possible.
>> [snorts] >> So, if they if they if this operator does not declare the nodes as being from the same family and these nodes are also running in different places, so they are not co-located, it would still be possible that two of them are chosen as entry and exit entry and exit of a user's connection.
Now, is there a solution for this? This can be made significantly harder with some form of operation operator verification and reputation system.
So, the idea is that operators that are would would be able to go through some sort of process where you you say, "Okay, this this operator of these 10 nodes is associated with some outside reputation." Like, for example, these are people known in the community or maybe they are part of like a non-for-profit or some organization or whatever, so that there is like some outside reputation that would suffer if these people are found to be misbehaving, meaning that they would be running nodes secretly that are not declared or that they would be colluding with some other operators, some other verified operators. So, the idea of verification is to introduce some trust in the system and some reputation that basically says, "Okay, if you're a verified operator, all your nodes are declared and you're not supposed to collude with anybody else."
>> [snorts] >> And this would lead to an an additional exclusion rule, which is that at least one of the nodes, entry or exit, must be run by a verified operator. It's enough that one of them is run by a verified operator in the sense that even if the other one would be like someone that is completely anonymous, they would need to have both entry and exit to be able to have the full path.
So, it's enough that one of them is not colluding for for this decentralization to work.
If this would be in place, this is something that we are considering for our next iteration. If this would be in place, then even if a malicious adversary has all kinds of nodes and they they are not declaring them, as long as they don't get if they are not verified which introduces the whole question of how would you get to this verification and what kind of assurances you would have, then this would basically eliminate the risk of anonymous sock puppets kind of being able to uh yeah, to be chosen as entry and exit of a connection of our connection.
Next slide. I don't know if this is the last one.
Yeah. So, just to be clear, what is a family and what it is not. So, a family is a set of nodes controlled by the same operator. And if you are an operator of of multiple nodes, you should declare them all in the same family and you should never have them in different families, okay?
So, not family declarations are introduced for security reasons, not for social purposes. So, it's not necessarily a social group. It's not that oh, you know, I have some friends and then we all join in a family and this is not the point. The point is does the same person control the the two nodes and if yes, then you don't have a decentralization. If they are different people making decisions independently, then you know, they are different operators and they should not be part of the same family.
So, a family can be the same as a squad if the if the if there is indeed like this this centralized this this control that all the nodes are controlled by the same entity, by the same organization, by the same decision-making.
But so yeah, a squad can be a node family, but node family is not necessarily a squad of a group of friends. It can be like just a single person, a single operator that is running multiple nodes.
And a family is a way for reputable operators to certify which nodes are under their control. So, if you if you have a good name in the community and you're running a number of nodes, you will be able to certify that these are really your nodes and if somebody's trying to use names similar to yours to pretend that they are all their node is also part of is also run by you, this will no longer be possible.
So, that assurance is is provided, but of course, the fact of declaring a family is not necessarily a guarantee that the operator is trustworthy because that's that's yeah, that's a much bigger question.
So, I think this is it from my side.
Over to next, yeah.
Hacks.
Yeah. Hello. Can you hear me, Sebi?
Yes, great. Hey guys, nice to be back.
So, after the sort of theory and and the concept rundown, what I want to show you is how this going to surface in the wallet.
Um the other but before I do that, the other bit I want to mention is that most VPN users going to meet this in its pure technical shape, basically not like all the automated connection algorithms would will not surface, you know, entry exit combination the same family or whenever two >> [clears throat] >> exit selection made, there's going to be like a warning like you selected two nodes from the same family. Do you wish to continue?
But all the other magic and I'm going to start sharing my screen now. So, hopefully so can you switch to the switch to my screen.
Let me know if you if you if you see it on the Figma the wallet UI.
And I need a yes verbally because I don't see the Can you see my shared screen?
Wallet landing.
I see it. We can see it. Nice. Thank you Sudo for for for the verbal confirmation. So uh there is a wallet map update coming out maybe it's already out or maybe very soon. This is a sequential so the next wallet update what we're already working on is going to look a little bit like this. And there is not much change on the on the dashboard side. There's only one extra thing that you can see here is basically right here on the account summary page.
Any wallet holder will have a family summary of their nodes.
Uh right now this demo is showing that I'm the owner of Alpine nodes family. It has four members. It has 2,500 Nyms bonded and my node is this one here on the example. Now there's actually two kind of use cases to consider. Either you're a you're the wallet owner of the family manager or or the one who's going to start the family in which you're going to basically start from this empty on a new family tab and you can family, create a family.
You can you know define the family name which is going to be Alpine nodes for the example. We require 100 Nyms to bond to disable spam attacks or to you know botted families appearing on chain.
And once I create this family uh I'm going to be transferred to something like this.
Now this is a screen which has all the warnings and all sorts of states so I can demo to you. Of course the first time when you create a family is going to be a little bit less crowded. But basically, what you're going to be able to see here as a family owner is that your status and then all the family members status, right? So, since this since the joining a family is going to be done on invitation basis to verify that from each wallet, you know, whoever is delegating access delegating their their node to a family has access to that key.
So, basically, a family owner can send out invites, invite members based on their uh node ID. Node ID here.
And once I have that node ID specified, I'm going to get this small warning that only proceed if this node is under your control directly or that, you know, with the full awareness that this node is already running and you know who this who you're sending this invite to. Because once you send this invite, basically, um um um um a member or a node runner would see a pending family invite something like this. It's not going to be 2 48 hours. It's going to be like a more bigger time window because I think it's just for a demo here. But basically, anyone who receives an invite will see which family is the invite coming from, who which are the other nodes who are in the family, and kind of has the option to either accept the invite or decline the invite.
Now, even when accepting the invite is also important to point out for if you accept an invite, you know, make sure that you know that you're delegating control, partial control for the time being, of your uh node to the family. And only proceed if you trust and know this operator if you're the operator too on the other side. And once you're done accepted this, maybe, then your node is going to get into the family list.
And uh but anytime anyone wishes to leave because they're going to spin up a new node or they kind of maybe I don't know, doing some other operations, you can just reach quit basically anytime from the family here.
Now, of course, if uh family owners can also kick anyone.
Let's say summit node is not doing well.
Uh it used to be a squad member who went AWOL for way too long time. And uh we we don't want this to degrade our family performance. So, just kicking the node.
Now, of course, families, as they can be created, they can be dissolved, but only a family only such family can be dissolved which has which has zero nodes. So, I have to kick all the nodes from here.
And then I can actually dissolve this family as a family owner.
And then there's no family here. Right.
So, I think I kind of covered everything. I hope this was uh in a good order. And if there's any questions, happy to answer in the end. And I'm going to pass it back to Serenko or or Mark, if I'm not mistaken.
Serenko, it is. Hello. Is it me? I don't know. Show the next slide, then we will see. Next slide, please.
It might be Mark, actually.
Mark hasn't spoken yet. Let's speak, Mark.
Hello, everyone. Uh not sure you can see the slides, so Oh, it is me. It is Serenko.
All right. On naming. Let's go next slide, please. And I'll then make sure that Mark has a lot of room.
The name is the mother of 10,000 things.
That's kind of my sub title or the first quote I put here out of many.
Just to connect the all ancient highlight that you know, the the creation of of the nameless uh being the origin, but then actually everything which became created being the name, and that that kind of going all the way to computer science. I have here a bit of Python, a bit of book of coding, and I'm pretty sure that anyone of you who's been a little bit around computers have been breaking their head about those hard to things, a particularly one, naming things.
And how naming matters. Uh next one, please.
Thank you. So, when we're going to be creating these families, as I said, there's already many squads, and that means that people have been having experiencing with uh putting names on their notes, on the node description.
Every node has description. Now, the family naming will not be the node description. It will be, as Hacks was showing, directly in the UX for an in the UI for the family will be a different endpoint later.
So, I want you to already start to be thinking about I'm creating a family. How am I going to construct that?
Let's try ourselves do the hard job of putting ourselves in the head of the user. I got to think I'm the user coming to the VPN application.
Um what is the user going to be looking like? Because through that you're building your reputation. So, you need to have some clarity, reflect what that name really means, have consistency, so maybe, you know, there's multiple people who can call you to their friend, maybe they'll join family together.
So, how can we be a bit more consistent with also naming of the nodes, and how my family can be a bit more consistent with the names of other families, so it kind of is like a bit of a network consistency, because we are decentralized, and that brings beauty, but diversity can exist only if there is also unity.
Without unity, there is no diversity, right?
We need a bit of a brevity, so things can be read like really quickly, directly, and short.
They need to be human-related, um because while machines are really good for reading things written for machines, these user-facing things are for people.
And most importantly, maybe I want us to think how we building more trust cuz let's not be too serious. We have jokes all the time when we come to the AMA, when we come to the uh to operator chat, we dropping jokes, emojis, memes all over the place. I mean, that's internet.
It's all about it.
But then we also like putting extra things which are coming to the people out there which know nothing about our circle, which know nothing about our community, and all they see is the name of your family, is the name of your nodes.
So, there needs to be a bit of a professionalism.
And maybe tune down a bit of a jargon, and the inside jokes or definitely something offensive. It's not it's not only that it's kind of bad taste, but you going to lose users before they would ever ever connect, right? They would see that and be like, "How am going to trust this or that name? It's offensive or it's want to be funny, but I might not connect through that."
So, you want to create names which people want to join as users using your nodes, and as others joining your family.
If you got your friends or like take an example from that. And my last slide, please.
I think there is still one more. Yeah, I I brought a few examples here.
Things Again, this is just names of nodes, but something I really like is if it fits.
Uh you don't see the last one under my I'm actually covering the last one, which are nice names, but they don't fit.
Thank you.
So, you see nodes have amazing operators, but then I open actually um the application and I see Indonesia gateway. I can guess it's a gateway, but there's also an index, which on nodes I really like, like you can see on a uh on the other nodes to the left.
Cuz the index can help me like that that node worked very well for me.
Or or it didn't, and maybe next time I'm going to use another one or it was kind of too populated or what what have you.
So, if the index is there or anything in the name is there and you don't see it, then it's like if it wasn't there. Most of the people wouldn't click on that, right? That's the same for the TSDC coin, something I can only imagine was there.
Then next nodes name staking, really nice one, but also maybe it would be nice if there is, you know, the the either the location or um some index or something. But again, this is just for nodes.
What what I want to stress, and I found myself as a user, I really like even though it's very short and concise, it's the code that I go home.
Because every I want to use residential IP instead of looking for it uh in in the UI, I just write to this huge hole, boop, it's there, I click on it, and I go.
The logic for families will be different than the logic for nodes.
But I'm just like trying to bring some of these examples on like how to think as a users and how to sometimes like realize what do users see, what they don't see, what might turn them into using your node again versus what might like make them kind of walk away.
All these examples I show here, none of them is bad. Uh please don't take this.
There have been terrible examples in few times, thankfully, and I don't want to bring them up, but yeah, let's let's have fun and sometimes we can even troll each other, but maybe not on interface for the users where it's also incentivized soon for us to be wanting to have those users putting those credentials on our gateways which we've been running.
That's going to directly translate into the rewards and into the quality of the network, also bringing more users who might have seen it as a friend, family members, or colleague at work.
Thank you and finally back to Mark.
Thanks Serinka.
All right, so let's just talk a little bit quickly about how this is going to be implemented. So, next slide, please.
>> [snorts] >> Um three rough phases. So, Hacks has shown you uh what the wallet will look like. So, that's where we're going to start there. Operators will be able to declare their node families, um add nodes, accept and reject invites, etc. Um and the algorithm that applies the routing policy is going to be used in gateways initially. So, that's just going to say that if you are trying to use the Nym VPN app, you won't be able to use gateways that come from either the same operator or if they are in the the same ASN.
Um and I'll go into a little bit of detail in that in a moment.
Um then we'll move on to doing this for uh mixnet nodes. It's a little bit more complicated because we need to change the way that layer selection works.
Um we can't have uh nodes that are um nodes that violate the routing policy um in they need to be in the correct layers.
And then the last one is to make this fully decentralized, we need to allow anybody to run a geolocation agent if they pass a governance proposal to be to be added because um there there is a uh blockchains don't really let you do network requests, so we need something to push this geolocation data um into into some contract state that we can then go and use it. Um Next slide, please.
So, what does this reading policy look like?
We're really just saying that when nodes have a declared family, um we won't let you choose them as an entry and exit for DVPN mode if they're in the same family.
So, that's so they don't come from the same operator. Um And that's maybe also worth saying that uh it it won't be fully enforced. It will be a warning. So, for example, if you run your own family and you trust both your nodes, you're welcome to use them.
>> [snorts] >> Um if uh if they're in the same ASN, so they could be different families, um but the same ASN.
So, there are uh records of um who is using IP ranges um on the internet.
And the ASN allows us to prevent people accidentally using two nodes that are inside probably the same data center or at least in the same ISP or or cloud provider.
Um and then lastly, are they on the same subnet?
So, it could just happen inside the usual thing, people spin up uh EC2 instances, and they run them in the same availability zone. They're very likely to be on the same subnet.
Um we we don't want that to happen, or if you're using collocated um hardware, you you don't want to accidentally be on the same subnet and have a problem um where where there's the ability to to spy on traffic that goes uh in physical networking equipment.
So, [snorts] that's that's sort of the the long and the short of it and this will implement what Claudia described earlier.
So, back to Sudo.
All right. So, for this one I'm bringing everyone back on screen and removing the deck.
Technical issues notwithstanding, hopefully you enjoyed this presentation and learn something as well.
Claudia, yes, full house.
All right. So, thank you for for the presentation folks and also big thanks for the attention from our audience and thank you for the great questions as well. We're going to pick up as many as we have time for.
First one is from Jake.
Jake asks, will node operators be compelled to group all of their nodes into a family when signing the terms of terms and conditions?
Yes.
Yes. Okay.
Now, Jake in his comment following comment he said to one of these questions, I don't know which one it was, but the answer was shared right when he asked the question. So, sorry if if I'm doubling some info that was already shared during the presentation. That was a quick answer. Thank you, Jaya.
Next one is also from Jake. I imagine that laziness would be the biggest threat to clear groupings of nodes into families. How can we how can we incentivize operators to do the work of linking their nodes into a family?
Claudia, maybe this is or or Jaya?
No, it's a great question and there's a few different incentives and one of them definitely I would like Claudia to to discuss a little bit more.
It touches on a topic that we were thinking to partially introduce in this town hall, but felt like a little bit going overboard um and that is ticket-based rewarding um which we have talked a bit about before. Um but there's of course other ways to incentivize also that have to do with um UI and just making sure that everything is like really easy to to manage. Um and uh kind of following on from the great node orchestration work that um Serghei has been doing with the community already, we do know that a lot of people are running multiple um nodes and if we can add a layer that makes it easier to run multiple nodes while also declaring a node family, we're hoping that that can be a you know a soft nudge. Um but in terms of the more kind of concrete uh incentives when it comes to rewarding, Claudia, do you want to say a few words on that?
Yeah, so um this will have some interactions with the ticket-based rewarding uh which um I guess people is are familiar with the concept which is that basically gateways will uh be collecting the tickets from the users they serve and then they will be rewarded on the basis of those tickets.
Now, the rewards are proportional to the amount of tickets that a gateway is getting, but they are capped by the amount of stake that the gateway has.
So, a gateway with small stake will be able to fully cash a few tickets, but at some point it maxes out and additional tickets do not bring additional revenue until this gateway is raising the staking cap so that more uh tickets can be can be rewarded. Now, if you have a family, what we can the plan is that uh the stake of the full family will act as a global cap. So, imagine you have two gateways and one is getting a lot of tickets and the other one is not getting so many tickets. By having them as part of the same family, you will be able to get fully rewarded for all the tickets while if you have these two as separate families, maybe you are capped on the one that has a lot of tickets and then you're getting fewer rewards. So, there is like some uh good interactions with the with the ticket-based rewarding that can be kind of used to further incentivize, although I agree with Yaya that having a nice interface for people who manage multiple nodes in order to be able to do it in a convenient way is probably the best antidote against the laziness problem.
Thank you for that answer.
Next up, and also thanks for the great questions, Jake.
Next up, I'm actually going to correct one of my mistakes. I forgot to mention that you can also leave your questions on our Matrix channel to preserve your privacy and not have to log in with your YouTube account. So, if you want to ask us any questions, then you can drop it on the general chat of the Nym Matrix server.
So, this is a this is a question from Matrix.
And the question is the following, can the node family flow we're demonstrating be done using a command line CLI tool instead of the Nym wallet app? This user's Mac OS version is too old to run the latest version of Nym wallet.
I think this one's for you, Hux, or no, actually maybe you, Mark. Go ahead.
>> No, I can I can answer that. So, do we definitely want this to be something that people can automate because you know, if you've got lots of nodes, it's going to be very difficult clicking through everything.
And Serinkoi and Hux already have plans afoot to put that into some of the automation tools that many of you will be familiar with already. It'll definitely be in in the Nym CLI.
Excellent.
Thank you for the question and thanks for the answer as well.
Next one is from Omar Mark Lee Ambrosio.
Is the Nym delegation program still open for new node operators? I guess this one is for you, Serinkoi, as the owner of the program.
Yes, welcome.
Omar Ambrosio, we would be happy to welcome you to Nym delegation family.
Uh please share a link in the chat now so the operator can and other operators can go there directly and apply. There's also rules in that link, so we would be happy to see around. Make sure you join the chats and hang out with us. We're a community where we can be a little bit less serious than what I was presenting in the morning naming.
All right, excellent. Uh maybe if you could drop while I'm asking the last question a link to the to the docs page of the um of the delegations program and then we can share it with the community.
Thank you and also thanks for the great question. Uh next one is from Rocío.
Um is the family structured by squad or by multi-node operator? And then also I will add her next question to this, which is uh can a squad have multiple families?
Um maybe the maybe for you, Jaya.
Yeah, I So um I don't know if you if you saw the slide. I think we did have that slide up of what what node families are and what they're not.
Um so node families are not exactly the same thing as a squad. So if your squad is basically a bunch of friends who come together and share a few tips on how to kind of run things, um that's that's fine. You can have multiple families, you know, each of you are an independent operator with your own keys running nodes. Um and you effectively control the nodes that you control, but if the if the squad runs nodes collectively, meaning you all have access to the keys and you all control those nodes or you're running it as a multi-sig um or you're running a kind of proper down with a multi-sig um then uh uh the situation is slightly different and then in that case, no, you know, you shouldn't be having multiple families.
So the way to think about it is do you control the nodes? If yes, it's a family.
Um and who you are, it might be a group or it might be an individual.
All right, hopefully that that answers that. Thank you for the Oh, sorry, go ahead. Go on.
>> are operationally independent? This is the key question. Yeah.
But there was also like a small a tease there, feature tease, because the word multi-sig was dropped by Jaye not by me.
So, you know, like if if you listen good enough, like >> [laughter] >> I I know but I think that's that's really important and great to point out that this schema that we are applying now is going to enable real DAO-like functioning on the Nym network between node operators. So, actually, we're going to we're planning to introduce uh multi-sig, so you can have real resilient DAOs, you know, collectively deciding on, you know, actions over keys.
And that way this would seamlessly work together with the family declaration model that we're implementing now. So, I think that's great and really forward-looking.
Excellent. Uh thank you for that uh quick alpha drop. When When When can we see it? WEM?
You know, you know the answer to that, though. It's very soon TM. I just wanted to tease it out.
All right, thank you for the great question and also the answer. Next one is also from Matrix and also from Oceanus. Um they asked the the previous question as well. And it goes, one more question from Matrix, uh Oceanus, can governance voting use a family-based model instead of voting um one node at a time? This is a good one.
This is more like a feature request, maybe? Cool cool idea. I think Yes. I mean I mean this this is what we are doing these events for. So, I think this is great great input and absolutely yes, why not? I mean that's like proper, you know, delegated democracy in a way. I think that's great and great that it's not coming from us because we just had to say yes. So, yeah, Claudia, go. I have a We we need to be careful to not disincentivize people from declaring families. If I'm going to go from 10 votes to one, Uh, that's a downside. So, if if we're going to do something like that, then maybe family size needs to have some sort of weight. Yeah, it's stake-based or something.
>> Yeah, or stake-based that that the the family is taken into account. We would still keep them we would still keep the the one or like the the stake Yeah, the stake-based model that we currently have, right? So, in that case, it's just it's actually a major incentive for people because the current uh voting setup is a bit uh cumbersome uh for those who run uh a lot of nodes.
Um so, you know, if you could just uh they they could just vote all at once, I think that would be uh maybe an actual incentive.
Thank you for the great question and actual like low-key hidden feature request. Um moving on to the next one.
Uh this one is also from Rocío.
Question: By maintaining a registry of operators for verification and reputation checks, how will this guarantee their anonymity? Mhm. So, um if you kind of looked carefully at the presentation, um the first phase of node families is not going to include verification.
Um basically, we're trying to keep it kind of very simple to start off. It's literally just, you know, operators declare families. The client can actually check, you know, whether you're in a family or not or whether you're in the same ASN or not in order to, you know, um modify what gateways are available. However, and that's that's basically to say that like the verification process is still something that we're kind of working out the nitty-gritty around. Um so, Claudia, if you you want to interrupt me at any point, do you just want to >> Yeah, I want to say that uh um you can still have pseudonyms reputation, right? Exactly. So, that's the point. Uh yeah. Yeah, so you can you your reputation might be tied to, for example, a Telegram account that uh that you use and maybe nobody knows your real name, but there is reputation attached and everybody knows that whatever this name in Telegram is the one uh operating these nodes, and then the reputation of the that is attached to the pseudonym would be transferred to the to the kind of the nodes operated by that verified operator. So, verification does not mean identity check.
It means a linkage to some outside source of reputation.
This can be identification. For example, if you would have a legal entity like a company or a non-for-profit running nodes, then indeed this verification would be like, yeah, really these people are the ones running these nodes and not like some impostor pretending to be them, right?
But the same hap- the same applies to to pseudonymous operators in the sense that you would still do the same verification to say like, yeah, these nodes are the ones run by whatever uh this name in Telegram and not some impostor pretending to be this person, right?
Um so, yeah, it's not about identification, it's about there is some form of reputation outside of the operations themselves that um means that this person has some stake, some uh something to lose if they are found to be misbehaving, right?
>> Skin in the game. Exactly. Some skin in the game that I mean uh maybe they would lose their following in in some social account or whatever if they are found to be cheating, right?
So, it's not necessarily about um I mean, you cannot be fully anonymous, but you can be pseudonymous because fully anonymous means that you would not have an identity even you know, you you would just be a different person every time. So, that with that you you cannot really work for building reputation.
>> [snorts] >> Um and linking that back to kind of Oceanus's question earlier also, um we are looking at kind of that pseudonymous tier um to potentially kind of have um some community um voting as part of the verification process as well. So, verification um might also look, you know, friendly decentralized and is part of kind of the existing operator community that's been with us for a long time.
Um and partially stake-based. So, yeah, it's it's not going to be, you know, um fully, you know, full identity checks um in the way that you're uh concerned about, Rocío.
All right. Thank you for those answers and thanks for another great question, Rocío. Next one is also from Jake.
Um how can we prevent How can we prevent a family key uh from claiming ownership of someone else's node? Will the node have to sign the membership claim uh for it to take effect?
Great question.
>> Yeah. I can answer that. Um so, yes, you will have to confirm. So, it it can't be that people can bring your node into a family if you don't want that to happen.
And then, you know, as Hak showed you as well, it's possible to leave as well uh later should you want to as the node operator per node.
That said, be very careful when you accept invite, you know, like make sure that you know what you do when you do it because this is, you know, on-chain action. And as such is eternally on the chain. You can still exit, but it's a yeah.
Don't accept candy from unknown uh node operators, node family owners, okay? Um All right. Uh thanks for that answer.
Uh and then lastly, uh a bit of unrelated, but I think great question from Ronnie. Apologies if this is off topic, uh but it uh is there an update as to when split tunneling will be available for iOS devices? Maybe this one is for you, Mark, no?
Yes, good question. So, uh iOS is really difficult for this. Um so, unfortunately, it's going to be the last one that we get to do. Um you know, in the meantime, um [clears throat] there are some options, and maybe uh you actually want to look at some of the uh geo exclusion um work that's coming out in one of the future releases that might actually be something that could could do what you need. Uh yeah, it's very difficult with iOS. Um the sandbox is very tight. It doesn't let you know which apps are running. Um it's really the most difficult one to do there. Um Apps that do do it the uh pretty shady things like they try and open special deep links to applications that they think you might have to identify them.
Um you know, so we've got to be uh >> [snorts] >> pretty careful about how we do this in a way that um it's done right.
Thanks for that answer. My understanding is that very few VPNs actually do split tunneling on iOS, right? It's It's that difficult. Yeah. Yeah. So um that's a soon TM, Ronnie. Sorry uh Sorry we had to crack another soon TM. But we're working on it.
But this is something that we actually we've been working a lot in the recent weeks. So this is not something that you know, we push aside. This has been super active development. And then trying to solutionize. And the fact of the matter is hard to do. So just hang in there a bit more. This this has been really want to have really want this to be out in the iOS, too.
Thank you for that answer. Go ahead, Jay. No, I was just going to say um I think we're coming up to to time. But um this was just obviously a first sneak peek of um node families. I think this is probably the first that um operators really hear about it. There's been a little bit of talk in the forum.
Um but we will put out some written material so you can kind of like take your time to really kind of think it through and obviously all the channels are open as usual on Matrix Telegram.
Um and the forum if you have um any additional questions. Um and Synapse will be continuing with the um regular AMAs um to also kind of deep dive on as we get closer to rolling it all out. Um so yeah, thanks everyone.
There's still one more question on the wrap-up to go, boss. Don't don't get out of get get ahead of yourself. So, the last question is from Ginny. Will the Nym team start their own official node family?
We already are a node family.
Very good.
Serinko with the press ready responses right there. Okay.
>> More than nodes. More than nodes, no?
>> [laughter] >> We got to We got to be testing things on mainnet. Not as let's test it on mainnet, but as let's test it on mainnet. We need nodes and to play with the same rules, we'll put them to the family. There is There is uh nothing non-transparent about it. You can find the nymtech.ch nodes. Those are our testing nodes on the mainnet because, you know, sandbox can never mitigate the same numbers like decentralized 750 nodes uh spread mainnet. So, we have nodes and we'll bond them to the family as one of those, you know, if you're going to all accept us, you will be one of one of those as well.
All right, excellent. And on that note, I actually I've been meaning to set up just to learn about how to set up a node. I'm not a very technical person, but maybe I will set up a node and create a bunch of nodes and then create a node family. No promises there though.
It's not even a soon TM. It's a maybe soon TM.
So, uh don't take that as a promise.
But, you can pressure me on chats and maybe I maybe then I'll end up doing it.
All right, and that was our last question for today. So, big thanks to all of our presenters for being here.
Any closing closing remarks for any of from any of you which maybe got left out from the from the presentation?
Naming is really hard and I really suck at it, so don't rush it. Now, we have this alpha, so think about it up front, so you're not going to end up like me in my comments and bunch of the things I'm writing because then, you know, it's too late. It's It's forever in the git, so on chain is even worse. Think about it.
My My last thought is that I've been just remembering when squads became a thing like 2 3 years ago or 2 years ago, she had the academy, squad squad league first you know. So compared to that we came a super long way and the network has matured a lot and this is now also like a maturing point and I think it's just really great to see that uh now it's growing up and we have to be really careful how we you know name us and how we declare who we belong to and I think it's great. It's nice to see.
And thank you all for you know for the for our listeners and the and the node operators community for being here with us because this this is actually the thing that you did you know we just prepared the grounds and and kind of maintaining this garden but you are the ones running this network so thank you all and uh yeah.
All right and that that really brings us to the end of this call I guess unless Jaya uh took a deep breath to say something. No, I was just going to say I can't I can't top the comments by Serinko Knox. [laughter] >> [gasps] >> All right so let's let's leave it there.
the community and so yeah. Yeah. I will have to do my closing though.
Unfortunately I have bad news for you ladies and gentlemen. Uh we don't have for the first time ever since we introduced POAPs for Nym community calls today we don't have one as the site that we use behind uh our POAP claiming mechanism is broken and we uh weren't able to fix it. So sorry for that. Uh maybe we can fix this by giving you two POAPs next community call. I'm not sure yet but we're going to rectify it in some way. Uh that's one thing and the other thing is also just uh tangentially related but I wanted to bring you something new. I'm going to send it in chat now. Um we've just started a survey about um a know like a Nym VPN subscription resell model. This is something that we are thinking about um or considering um uh launching. Nothing is for sure yet uh but this is a uh a survey that may be interesting to you. So if you run nodes and maybe you have your own website or anything like that you may be interested in reselling Nym VPN subscriptions if we end up launching this uh and uh to basically uh get ideas from you and understand better like how would you want a feature like this to work. We created a survey, a link to it was dropped in chat and we will also share it all across our socials. Please fill it out so we can get a better understanding of what your needs would be if we ended up launching this service, whether you're interested or not. There's good questions there and it would help us greatly and maybe, you know, we could work together in this capacity as well in the future. With all of that said, I'm going to wrap up here. A big thanks everyone for for joining us. Also big thanks to the presenters. If you have any questions or concerns about any of the stuff discussed, then you can reach us on any of our various community channels.
Have a great day everyone and see you around. Bye.
Ähnliche Videos
Trump's Crypto Bill Just Cleared Committee—Here's What It Actually Does
UNFTR
290 views•2026-05-16
HUGE QUANT BREAKOUT!🚨 | QUANT (QNT) PRICE PREDICTION & NEWS 2026!
CilinixCrypto
144 views•2026-05-16
How is crypto exposure risk being managed by long-term XRP holders? #xrp #crypto
JakesDigitalAccessionGroup
120 views•2026-05-16
The $1M Bitcoin Flaw Nobody's Talking About
bitcoinnewscom
161 views•2026-05-21
Don’t Sell Crypto — Borrow BTC Against It (How Crypto Loans Work)
kqqkqqkq
242 views•2026-05-16
HBAR JUST IN: US Insurance Integration is OFFICIAL
CheekyCryptoNews
143 views•2026-05-15
The XRP Myth: $1 Today = $100 Tomorrow?
odes_ai
2K views•2026-05-18
Kaspa’s Next 30 Days Could Change Everything
cruxofcrypto
501 views•2026-05-18











