7 ms·

Building a decentralized name system on top of IRC

85 points by Uptrenda 3y ago

charcircuit 3y ago
There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with.
- Uptrenda 3y ago
  >There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. There is zero security if you dismiss every such measure to accomplish a level of security by saying that its just 'random crypto' that doesn't accomplish anything (why do you say that?) >Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. I think there may be some confusion in your understanding of the system. Registered names aren't visible, only their hashes. The design masks names through a verifiable delay function which forces registering parties to do lengthy computations to construct the lookup function. Since computations can be stored in bulk - names can be registered atomically across IRC servers without revealing what they are directly. >Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. In the context of networking 'sybils' refer to being able to create multiple identities, machines, or so on controlled by the same person. But your usage of the term here is confusing because (1) users don't control third-party servers (2) users can't see names directly (3) there is a cost to creating names (4) and a threshold system is used to do consensus over name lookups and registrations (which was designed to solve the problem you're talking about.) >The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with. I would love to use a blockchain for this. There's only one problem. Currently there are no such blockchains that have zero transaction fees to use them. I think that such a system would be very useful. But it seems that no one wants to do it -- and working at blockchain startups for more than a decade has taught me that bolting forced monetization and funky tokens onto everything can make a system worse (or even unusable) for its intended purpose. I think if you re-read the post you will see how I've addressed the problems you raised.
  - charcircuit 3y ago
    >why do you say that? Because the information needed to lookup a name is equivalent to the information needed to register the name. >Registered names aren't visible, only their hashes. But domains are public information. Imagine if in normal DNS anyone could register google.com at any time. Claiming that its not insecure because people don't know google.com exists doesn't make sense. >names can be registered atomically across IRC servers without revealing what they are directly. But if someone learns the name they can register it themself. Two people can both claim to be google.com. If a new IRC server is added anyone can create a channel for an existing domain. If your answer to the problem of the same domain being registered by multiple people is that a domain should be both a name and an encrypted nonce you run into the problem where it might be more convienent to just pass over the public key. >But your usage of the term here is confusing That is my fault, I assumed this was a permissionless system where any IRC server was permitted to be used instead of a permissioned one. >Currently there are no such blockchains that have zero transaction fees to use them. Some cost near $0. A fork of one could be made to do so.
    - Uptrenda 3y ago
      The channel names are unique per server. Knowing the channel name isn't enough to infer what name it represents so you can't just go and register the name on other servers after observing channel names. The only way to know what a channel name represents is to do a lengthy computation for a possible name, tld, password (optional), and server. Depending on uniqueness -- this might not be practical. The idea of having masked names was only to prevent race conditions in the initial registration process. After the channel names are registered they are unavailable for other attackers to register and since a verifiable delay has to be done on the name to compute it -- there is adequate time to register the name across multiple servers. A malicious server can reuse a channel name and have it hijacked by an operator. But the system also ties in ECDSA signatures with a basic threshold consensus algorithm across servers. So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name.
      - charcircuit 3y ago
Retr0id 3y ago
I don't know how else to say it, this is a really bad idea. It's spam. If you scale this up, the few IRC servers that currently accept this type of behaviour will start blocking it. You might as well be trying to use blog comment sections as k/v stores.
- Uptrenda 3y ago
  Spam is unwanted messages that displace what you want to see. In IRC: channels can be set to private which hide them from the channel listing. So that the server continues to operate in the same way. The software isn't doing anything outside of what is already allowed by these servers. Everything from the number of channels a user is allowed to create to limitations on expiry are already factored in to how people use the service. If a channel typically attracts users and their discussion increases as more people join, which may happen over a very long time frame, then I argue that my design is actually less impactful than a traditional channel. Since it is not designed for discussion.
  - Retr0id 3y ago
    Spam is any unwanted activity. It's visible to the service operators, and I predict that it'll annoy them, and they'll try to stop it. Apart from anything else, it'd start filling up their disks if it was widely used. Have you asked the opinion of any IRC admins?
  - aunderscored 3y ago
    This kind of thing falls under spam. IRC networks are not your infrastructure to use for any project. At the very least, I can tell you that Libera would define this as abuse and actively remove it. Our servers are for users to chat, not for software to communicate. And to clarify on spam, this takes resources from the target of a given network. If that networks target is to be a platform for software communication, sure. But in general, IRC networks are there to relay chat, hence the Internet Relay Chat name. This kind of thing takes processing power away from users, and increases memory load on the server. Not to mention bloating it's services database.
heapwolf 3y ago
if you're looking for an easier way to build p2p applications, you might be interested in the Socket runtime (https://github.com/socketsupply/socket https://github.com/socketsupply/socket)
- Uptrenda 3y ago
  Looks like an interesting project. When I was building my library I considered UDP hole punching but decided to focus exclusively on TCP because of how bad UDP is to work with. The issue with UDP is you're going to have to write a poorman's TCP stack on top of it. The approach used by this library for NAT determination also seems to be an over-simplification of how NATs work in routers (which is the same problem that Libp2p has) and will result in having hole punching code that barely works. Some properties to consider: - delta type -- this refers to how the NAT assigns external ports for mappings - delta value -- this refers to any known patterns observed in the mapping - nat type -- no NAT, UDP firewall, full cone nat, etc There are special rules for how traversal can be accomplished depending on the variables above. It's quite complex. But supporting it all greatly increases the chance of punching success. Another issue I see with this library (and this is personal preference) is the massive amounts of re-inventing the wheel (again -- Libp2p and Protocol Labs are notorious for this.) It seems like there are many custom protocols that you've built into your software but most of what you've built is already part of standard Internet protocols (e.g. STUN)
  - littlecranky67 3y ago
    > The issue with UDP is you're going to have to write a poorman's TCP stack on top of it. You can leverage a QUIC implementation nowadays for that - QUIC brings everything you need (session layer, congestion/flow control etc.).
  - heapwolf 3y ago
    actually using UDP is the whole point. we explain why it's superior to TCP in the guides (https://socketsupply.co/guides/#p2p-guide_how-p2p-works_why-udp https://socketsupply.co/guides/#p2p-guide_how-p2p-works_why-...). and our NAT traversal success rate is comprehensive, every known routable path actually works (check this table https://socketsupply.co/blog/the-next-chapter-in-the-story-of-cloud-computing/ https://socketsupply.co/blog/the-next-chapter-in-the-story-o...) we're actually not reinventing too many wheels here, our work is conceptually based on DTNs — cited frequently in our guides and docs.
JUNGLEISMASSIVE 3y ago
[dead]
dontdoxxme 3y ago
This is really abuse of public infrastructure if you really want to do this, look at veilid (https://veilid.com/ https://veilid.com/). Veilid provides modern crypto primitives to do this and more importantly the people running the network actually want you to use it like this.
- Retr0id 3y ago
  pkarr is another project in this domain https://github.com/Nuhvi/pkarr https://github.com/Nuhvi/pkarr
  - Uptrenda 3y ago
    This is not human-readable and centralized. It can't be used as a name system
    - Retr0id 3y ago
      ditto veilid, which is what I was responding to.
- Uptrenda 3y ago
  What part of Veilid provides a key-value store for DNS as a service? I'm not seeing anything on the site that mentions it.
  - Retr0id 3y ago
    veilid itself basically just provides a p2p backbone (where peers are identified by their public keys) on which you can build other applications. i.e. it's the replacement to the "random public IRC servers" part of this equation, and not the DNS-like system as a whole.
    - JanisErdmanis 3y ago
      What are assumptions involved for submitting and retrieving node’s IP address with a given public key to a Veilid network? For instance how does new users discover other Veilid nodes. Are those baked in statically? What happens if public IP addresses of the network change?
magicalhippo 3y ago
I just skimmed, but didn't see any mention of netsplits[1], and how to handle them? Seems like a pretty grave omissions for something that should be somewhat reliable. [1]: https://irc.wiki/Netsplit https://irc.wiki/Netsplit
bulla 3y ago
What are the problems with using Digital Object Architecture to replace DNS?
Geisterde 3y ago
Neat, its always good to see people experimenting on a better DNS system. As others have mentioned, there are alternative systems to IRC, and I think you should consider them and what system of incentives are created by what choices you make. You are using someone elses infrastructure, and even if you have done everything possible to minimize their overhead, you are still planning to use them for free. I think the other suggestions made here regarding options all have merits that I am not qualified to speak on; but I do know that decentralized/federated DNS is something highly sought after in bitcoin circles like on stackernews and nostr. You could use nostr very similarly to how you use it with your current implementation; I would very much love to use it to make remote access to services on my home network more accessible, and to allow others to use those services as well. There is a built in userbase of people that would like to host everything from cloud backups to online marketplaces to browser games, but using a centralized DNS is simply not an answer for them.
miki123211 3y ago
> DNS costs money to use (which I argue is not suitable for all uses.) This kind of thinking is a trap that I see many people fall into. Domains cost money because they have to cost money. Human-friendly names are a scarce resource (there can only be one google.com and one @johnsmith). They have value, and the market tends to reach equilibrium. If a scarce resource costs (or is given away for) less than some people are willing to pay for it, speculators will grab it and resell it for the "right" price. Free domains for everybody actually means free domains for an enterprising businessman who grabs all of them with a simple Python script in 24 hours, and then resells them for $10 a pop. We already see that with normal DNS, short and memorable domain names go for astronomical amounts, but because every registration costs money, registering more unusual domain names if you don't actually have a need for them is not a profitable strategy, and so good enough names can still be registered somewhat cheaply. You need to increase prices to make speculation unprofitable while still remaining affordable to end users. It's a balancing act. If you don't create the barrier to entry yourself, the barrier to entry will be created for you, and not in a way you like or can control. Such a barrier doesn't have to be monetary, it can be (difficult) proof of work, centralized identity verification and abuse prevention policies, legal consequences for scalping, invitation / vouching requirements etc, but a barrier always exists, whether created by the system developers or the free market. This only applies at large scales of course, if your system is used by 10 people and all of them trust each other, "grab any name you want for free" is totally fine.
- RicoElectrico 3y ago
  Having a programmer understand the economic and societal background when they create a new project seems to be a bold assumption. Obviously tech can solve everything, right?
  - test6554 3y ago
    I'm still waiting for the OAuth-based online US government ID for all citizens that lets us sign up for utilities, apply for colleges and loans, set up bank accounts, etc. instead of entering social security numbers everywhere. When is that coming?
  - 3y ago
redserk 3y ago
I really don’t understand the “why” here. As a toy project it’s interesting but the actual justification to actually use IRC seems to come after the implementation. This isn’t derived from the stability of IRC itself but the network operators as there are many holes not accounted for. You’re not guaranteed a channel on IRC networks. A network owner may decide to remove it or, if using Services, transfer ownership if someone requests. Same for nicks and other things. I’d also be willing to bet the network operators did not sign up to host a database for free for some stranger online either.
genpfault 3y ago
KadNode[1]? [1]: https://github.com/mwarning/KadNode https://github.com/mwarning/KadNode
- squarefoot 3y ago
  Very interesting, thanks for posting. Although by using the Kademlia infrastructure, which is also used by the eMule network, it could be blocked by some ISPs.
catapart 3y ago
This is a really interesting project! I'm very inclined to get my hands on it and try to use it for something, mainly as a way to circumvent WebRTC traversal. I really have trouble with the TURN server scheme as a way to connect obfuscated machines. That part makes WebRTC feel "decentralized, UNTIL...", whereas your scheme seems more "decentralized, IF NECESSARY...", which feels less like a potential roadblock and more like a potential emergency use-case. I get why people are concerned about using other people's infra for this kind of thing. But I do see a use-case for that as a backup. I don't think I'd ever implement something like this without running my own server as the enforced source instance for my apps so long as my server was running. If every other IRC server wanted to prevent this kind of scheme from working on their machines, I certainly wouldn't hold it against them. But I imagine that if other people wanted to run a P2P app, they might have their own IRC instances and would be accommodating of my downtime, as I feel like I would be accommodating of theirs. Different strokes, and all, but I definitely see how this would be pretty analogous to regular IRC usage, as far as administration and data, so I don't have any particular grudge against it - at least not without looking at what kind of traffic tsunami it could eventually cause.
KingOfCoders 3y ago
NickServ!
Uptrenda 3y ago
Hey people, I wanted to say thanks for all the comments: positive and negative. I've probably written hundreds of thousands of lines of code for projects over the years that had no interest at all. I am fairly good at engineering but very bad at choosing problems to work on. You have no idea how motivating it is for me to even have a single comment on anything I'm working on or thinking about. No one I know is that technical and I'm not part of any communities that would get a project like this. Most of the time when I share something there are zero comments and it just ends up being invisible. So thanks. This will motivate me to keep working on my main project (p2pd) to make it stable and start writing program that I can run on a daily basis ('dog fooding.')
forgotpwd16 3y ago
Although interesting, have to also agree with others that this is bad idea regarding to potentially considered abuse to good-will run servers. >Here sha3_256 is used again but this time inside hash160. The reason for this is stacking hash functions can help reduce the chances of finding collisions (you would need to find a collision in both functions.) Don't you only need to find collision in the outer hash function?

85 points by Uptrenda 3y ago

There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with.

Uptrenda 3y ago
>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. There is zero security if you dismiss every such measure to accomplish a level of security by saying that its just 'random crypto' that doesn't accomplish anything (why do you say that?) >Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. I think there may be some confusion in your understanding of the system. Registered names aren't visible, only their hashes. The design masks names through a verifiable delay function which forces registering parties to do lengthy computations to construct the lookup function. Since computations can be stored in bulk - names can be registered atomically across IRC servers without revealing what they are directly. >Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key. In the context of networking 'sybils' refer to being able to create multiple identities, machines, or so on controlled by the same person. But your usage of the term here is confusing because (1) users don't control third-party servers (2) users can't see names directly (3) there is a cost to creating names (4) and a threshold system is used to do consensus over name lookups and registrations (which was designed to solve the problem you're talking about.) >The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with. I would love to use a blockchain for this. There's only one problem. Currently there are no such blockchains that have zero transaction fees to use them. I think that such a system would be very useful. But it seems that no one wants to do it -- and working at blockchain startups for more than a decade has taught me that bolting forced monetization and funky tokens onto everything can make a system worse (or even unusable) for its intended purpose. I think if you re-read the post you will see how I've addressed the problems you raised.
- charcircuit 3y ago
  >why do you say that? Because the information needed to lookup a name is equivalent to the information needed to register the name. >Registered names aren't visible, only their hashes. But domains are public information. Imagine if in normal DNS anyone could register google.com at any time. Claiming that its not insecure because people don't know google.com exists doesn't make sense. >names can be registered atomically across IRC servers without revealing what they are directly. But if someone learns the name they can register it themself. Two people can both claim to be google.com. If a new IRC server is added anyone can create a channel for an existing domain. If your answer to the problem of the same domain being registered by multiple people is that a domain should be both a name and an encrypted nonce you run into the problem where it might be more convienent to just pass over the public key. >But your usage of the term here is confusing That is my fault, I assumed this was a permissionless system where any IRC server was permitted to be used instead of a permissioned one. >Currently there are no such blockchains that have zero transaction fees to use them. Some cost near $0. A fork of one could be made to do so.
  - Uptrenda 3y ago
    The channel names are unique per server. Knowing the channel name isn't enough to infer what name it represents so you can't just go and register the name on other servers after observing channel names. The only way to know what a channel name represents is to do a lengthy computation for a possible name, tld, password (optional), and server. Depending on uniqueness -- this might not be practical. The idea of having masked names was only to prevent race conditions in the initial registration process. After the channel names are registered they are unavailable for other attackers to register and since a verifiable delay has to be done on the name to compute it -- there is adequate time to register the name across multiple servers. A malicious server can reuse a channel name and have it hijacked by an operator. But the system also ties in ECDSA signatures with a basic threshold consensus algorithm across servers. So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name.
    - charcircuit 3y ago

Retr0id 3y ago

I don't know how else to say it, this is a really bad idea. It's spam. If you scale this up, the few IRC servers that currently accept this type of behaviour will start blocking it. You might as well be trying to use blog comment sections as k/v stores.

Uptrenda 3y ago
Spam is unwanted messages that displace what you want to see. In IRC: channels can be set to private which hide them from the channel listing. So that the server continues to operate in the same way. The software isn't doing anything outside of what is already allowed by these servers. Everything from the number of channels a user is allowed to create to limitations on expiry are already factored in to how people use the service. If a channel typically attracts users and their discussion increases as more people join, which may happen over a very long time frame, then I argue that my design is actually less impactful than a traditional channel. Since it is not designed for discussion.
- Retr0id 3y ago
  Spam is any unwanted activity. It's visible to the service operators, and I predict that it'll annoy them, and they'll try to stop it. Apart from anything else, it'd start filling up their disks if it was widely used. Have you asked the opinion of any IRC admins?
- aunderscored 3y ago
  This kind of thing falls under spam. IRC networks are not your infrastructure to use for any project. At the very least, I can tell you that Libera would define this as abuse and actively remove it. Our servers are for users to chat, not for software to communicate. And to clarify on spam, this takes resources from the target of a given network. If that networks target is to be a platform for software communication, sure. But in general, IRC networks are there to relay chat, hence the Internet Relay Chat name. This kind of thing takes processing power away from users, and increases memory load on the server. Not to mention bloating it's services database.

heapwolf 3y ago

if you're looking for an easier way to build p2p applications, you might be interested in the Socket runtime (https://github.com/socketsupply/socket https://github.com/socketsupply/socket)

Uptrenda 3y ago
Looks like an interesting project. When I was building my library I considered UDP hole punching but decided to focus exclusively on TCP because of how bad UDP is to work with. The issue with UDP is you're going to have to write a poorman's TCP stack on top of it. The approach used by this library for NAT determination also seems to be an over-simplification of how NATs work in routers (which is the same problem that Libp2p has) and will result in having hole punching code that barely works. Some properties to consider: - delta type -- this refers to how the NAT assigns external ports for mappings - delta value -- this refers to any known patterns observed in the mapping - nat type -- no NAT, UDP firewall, full cone nat, etc There are special rules for how traversal can be accomplished depending on the variables above. It's quite complex. But supporting it all greatly increases the chance of punching success. Another issue I see with this library (and this is personal preference) is the massive amounts of re-inventing the wheel (again -- Libp2p and Protocol Labs are notorious for this.) It seems like there are many custom protocols that you've built into your software but most of what you've built is already part of standard Internet protocols (e.g. STUN)
- littlecranky67 3y ago
  > The issue with UDP is you're going to have to write a poorman's TCP stack on top of it. You can leverage a QUIC implementation nowadays for that - QUIC brings everything you need (session layer, congestion/flow control etc.).
- heapwolf 3y ago
  actually using UDP is the whole point. we explain why it's superior to TCP in the guides (https://socketsupply.co/guides/#p2p-guide_how-p2p-works_why-udp https://socketsupply.co/guides/#p2p-guide_how-p2p-works_why-...). and our NAT traversal success rate is comprehensive, every known routable path actually works (check this table https://socketsupply.co/blog/the-next-chapter-in-the-story-of-cloud-computing/ https://socketsupply.co/blog/the-next-chapter-in-the-story-o...) we're actually not reinventing too many wheels here, our work is conceptually based on DTNs — cited frequently in our guides and docs.

JUNGLEISMASSIVE 3y ago

[dead]

dontdoxxme 3y ago

This is really abuse of public infrastructure if you really want to do this, look at veilid (https://veilid.com/ https://veilid.com/). Veilid provides modern crypto primitives to do this and more importantly the people running the network actually want you to use it like this.

Retr0id 3y ago
pkarr is another project in this domain https://github.com/Nuhvi/pkarr https://github.com/Nuhvi/pkarr
- Uptrenda 3y ago
  This is not human-readable and centralized. It can't be used as a name system
  - Retr0id 3y ago
    ditto veilid, which is what I was responding to.
Uptrenda 3y ago
What part of Veilid provides a key-value store for DNS as a service? I'm not seeing anything on the site that mentions it.
- Retr0id 3y ago
  veilid itself basically just provides a p2p backbone (where peers are identified by their public keys) on which you can build other applications. i.e. it's the replacement to the "random public IRC servers" part of this equation, and not the DNS-like system as a whole.
  - JanisErdmanis 3y ago
    What are assumptions involved for submitting and retrieving node’s IP address with a given public key to a Veilid network? For instance how does new users discover other Veilid nodes. Are those baked in statically? What happens if public IP addresses of the network change?

magicalhippo 3y ago

I just skimmed, but didn't see any mention of netsplits[1], and how to handle them? Seems like a pretty grave omissions for something that should be somewhat reliable. [1]: https://irc.wiki/Netsplit https://irc.wiki/Netsplit

bulla 3y ago

What are the problems with using Digital Object Architecture to replace DNS?

Geisterde 3y ago

Neat, its always good to see people experimenting on a better DNS system. As others have mentioned, there are alternative systems to IRC, and I think you should consider them and what system of incentives are created by what choices you make. You are using someone elses infrastructure, and even if you have done everything possible to minimize their overhead, you are still planning to use them for free. I think the other suggestions made here regarding options all have merits that I am not qualified to speak on; but I do know that decentralized/federated DNS is something highly sought after in bitcoin circles like on stackernews and nostr. You could use nostr very similarly to how you use it with your current implementation; I would very much love to use it to make remote access to services on my home network more accessible, and to allow others to use those services as well. There is a built in userbase of people that would like to host everything from cloud backups to online marketplaces to browser games, but using a centralized DNS is simply not an answer for them.

miki123211 3y ago

> DNS costs money to use (which I argue is not suitable for all uses.) This kind of thinking is a trap that I see many people fall into. Domains cost money because they have to cost money. Human-friendly names are a scarce resource (there can only be one google.com and one @johnsmith). They have value, and the market tends to reach equilibrium. If a scarce resource costs (or is given away for) less than some people are willing to pay for it, speculators will grab it and resell it for the "right" price. Free domains for everybody actually means free domains for an enterprising businessman who grabs all of them with a simple Python script in 24 hours, and then resells them for $10 a pop. We already see that with normal DNS, short and memorable domain names go for astronomical amounts, but because every registration costs money, registering more unusual domain names if you don't actually have a need for them is not a profitable strategy, and so good enough names can still be registered somewhat cheaply. You need to increase prices to make speculation unprofitable while still remaining affordable to end users. It's a balancing act. If you don't create the barrier to entry yourself, the barrier to entry will be created for you, and not in a way you like or can control. Such a barrier doesn't have to be monetary, it can be (difficult) proof of work, centralized identity verification and abuse prevention policies, legal consequences for scalping, invitation / vouching requirements etc, but a barrier always exists, whether created by the system developers or the free market. This only applies at large scales of course, if your system is used by 10 people and all of them trust each other, "grab any name you want for free" is totally fine.

RicoElectrico 3y ago
Having a programmer understand the economic and societal background when they create a new project seems to be a bold assumption. Obviously tech can solve everything, right?
- test6554 3y ago
  I'm still waiting for the OAuth-based online US government ID for all citizens that lets us sign up for utilities, apply for colleges and loans, set up bank accounts, etc. instead of entering social security numbers everywhere. When is that coming?
- 3y ago

redserk 3y ago

I really don’t understand the “why” here. As a toy project it’s interesting but the actual justification to actually use IRC seems to come after the implementation. This isn’t derived from the stability of IRC itself but the network operators as there are many holes not accounted for. You’re not guaranteed a channel on IRC networks. A network owner may decide to remove it or, if using Services, transfer ownership if someone requests. Same for nicks and other things. I’d also be willing to bet the network operators did not sign up to host a database for free for some stranger online either.

genpfault 3y ago

KadNode[1]? [1]: https://github.com/mwarning/KadNode https://github.com/mwarning/KadNode

squarefoot 3y ago
Very interesting, thanks for posting. Although by using the Kademlia infrastructure, which is also used by the eMule network, it could be blocked by some ISPs.

catapart 3y ago

This is a really interesting project! I'm very inclined to get my hands on it and try to use it for something, mainly as a way to circumvent WebRTC traversal. I really have trouble with the TURN server scheme as a way to connect obfuscated machines. That part makes WebRTC feel "decentralized, UNTIL...", whereas your scheme seems more "decentralized, IF NECESSARY...", which feels less like a potential roadblock and more like a potential emergency use-case. I get why people are concerned about using other people's infra for this kind of thing. But I do see a use-case for that as a backup. I don't think I'd ever implement something like this without running my own server as the enforced source instance for my apps so long as my server was running. If every other IRC server wanted to prevent this kind of scheme from working on their machines, I certainly wouldn't hold it against them. But I imagine that if other people wanted to run a P2P app, they might have their own IRC instances and would be accommodating of my downtime, as I feel like I would be accommodating of theirs. Different strokes, and all, but I definitely see how this would be pretty analogous to regular IRC usage, as far as administration and data, so I don't have any particular grudge against it - at least not without looking at what kind of traffic tsunami it could eventually cause.

KingOfCoders 3y ago

NickServ!

Uptrenda 3y ago

Hey people, I wanted to say thanks for all the comments: positive and negative. I've probably written hundreds of thousands of lines of code for projects over the years that had no interest at all. I am fairly good at engineering but very bad at choosing problems to work on. You have no idea how motivating it is for me to even have a single comment on anything I'm working on or thinking about. No one I know is that technical and I'm not part of any communities that would get a project like this. Most of the time when I share something there are zero comments and it just ends up being invisible. So thanks. This will motivate me to keep working on my main project (p2pd) to make it stable and start writing program that I can run on a daily basis ('dog fooding.')

forgotpwd16 3y ago

Although interesting, have to also agree with others that this is bad idea regarding to potentially considered abuse to good-will run servers. >Here sha3_256 is used again but this time inside hash160. The reason for this is stacking hash functions can help reduce the chances of finding collisions (you would need to find a collision in both functions.) Don't you only need to find collision in the outer hash function?