> On 3/16/24 17:08, carlo von lynX wrote: > > No, there are machines that *need* to be online, but there are > > always human beings that *like* to have machines always online > > even if they don't need it for GNUnet.
On Sat, Mar 16, 2024 at 07:54:56PM +0200, MSavoritias wrote: > Again thats where we disagree. I disagree that always online systems are > thing to strive for. At any layer of a network system. It was a typo. That are NO machines that *need* to be online, but acknowledging that some people *will* make "supernodes" and ensuring that such behaviour doesn't influence the aims of the project is relevant. It's been a while since I was on Bitmessage, but wasn't it one of the problems that by not planning for supernodes the network ended up being totally dependent on those who would run them? > Of course a super node has advantages. Social ones for starters. Any "super > node" that makes things run "smoother" will have social power. How? People would not even find out. Pretending like nobody will do this isn't helpful. > The tradeoffs were mentioned maybe you missed them: > > > for accessibility, for equality, for autonomy and the environment I missed them because none apply. A problem in accessibility only exists if there are NO nodes in the backbone and you're completely dependent on reaching people on their mobile phones with huge latency, big costs, needless radio pollution, since a lot of the traffic goes through the node merely for routing and obfuscation purposes. What's the gain having a supernode regards equality? Autonomy, well, only in the sense that your node will probably be dealing with data from nodes that are dear to you the most, but you're always also giving away to the wider social graph. And the environment? In fact if the routing traffic stays in the Internet backbone, it is much better for the environment then when it goes in and out of the mobile phone network all the time. That's in fact pretty irresponsible. Not as bad as Bitcoin, but heading that way. > > > Personally its simple I don't want to reinvent everything. Also our goals > > > are radically different as I have mentioned. > > I think bikes with square wheels are fine, I don't want to invent a round > > wheel! > > Ok I feel like you are on purpose trying to ridicule arguments instead of > trying to engage in good faith here. You are the one ignoring massive amounts of criticism on XMPP and just insisting on your point of view as if it was enough to have one. The Internet is full of opinions. Better have facts. > > > I don't want scale or servers/nodes. > > Then you don't want adoption by the human race, just by small groups? > > The question is not why I dont want it to scale. The question to ask is: Why > do we need it to scale in the first place Because we are billions on this planet and denying people to be interested in one particular source of information all at the same time is a no-go. It simply means they will not adopt our technology and we failed to replace the cloud Internet. We will not be able to fulfil any radio/TV-like use case, and that's inacceptable. > I invite you to read https://ar.al/2020/08/07/what-is-the-small-web/ the > small web and https://permacomputing.net/ on why things dont have to scale. Aral has said and written a lot of wise things and most of all he's a great communicator, but some of his thoughts simply aren't thought through. We already have plenty of small webs - just make your own website and share it with your friends: WOW. But nothing of that serves to address most use cases of what people really need. Simply being able to address the people you care for in order to be able to transmit something is a problem that needs a solution that scales, and BGP is not top notch in that regard. So the idea that the Internet can be replaced by something that doesn't scale is suffering from a huge lack of encompassing vision. > You mean scientific like: > > > I think bikes with square wheels are fine, I don't want to invent a round > wheel! Yes, please provide facts, not just opinions. XMPP is an inefficient mess and you are in denial of that. GNUnet is a small island that maintains a scientific approach and tries to steer clear from hype and assumption that something is good just because it got promoted to an RFC. There are countless crap RFCs. You can even buy them to be like this rather than to be like that, and somebody back in 1999 decided that scalability was not going to be in XMPP. > > And the spammers that you are talking about do not even have the > > address necessary to reach a recipient, because they can neither > > be guessed nor enumerated. > > But like what if I have published my address in mastodon? > > I was reading the https://secushare.org/rendezvous page and it actually > doesn't say anything about the usecase of how is a person allowed to contact > you. > > In the sense that capabilities in networks of consent work like this: > > I delegate a token to my friend to "introduce" people to me and only people > that possess the token can actually contact me. and of course with all the > usual guarantees capabilities provides. So you can put that token on mastodon. Same problem again. > Is secushare allowing people to contact me without me explicitly allowing > them to? Because in the above scenario even if they had my ego they still > wouldn't be able to contact me. If you really were unwise enough to make your cryptographic routing address available, an attacker can't do anything except try to DoS the node (which i bet GNUnet has means to deal with). In order to be able to talk to a person, you need to be in their social graph, that is, their node must automatically be able to see how little or much you are socially connected to them. Thanks to cryptography that doesn't imply that you get to see exactly who is friends with whom, but whether the person that is trying to contact you is a human being you are likely to want to communicate with. It's a bit like your idea of tokens, only that it is deeply ingrained in the protocol and routing and is always there for any "social" decision your software needs to make in order to not bother you with improper requests. So, even if an attacker manages to reach a user, they will not see the attack. They might at best find out about it "in the logs" if they are tech-savvy to care. > secushare seem to even have a discovery mechanism which doesnt even mention > if its opt-in. And I am talking about all layers for this here. from traffic > to pages to chat. Many things may appear obvious to the person writing a website that they can end up incomplete and easily misunderstood. And things that seem to be a problem may actually have very easy solutions. The problem is getting to the point of actually implementing any of that, given that the foundations of GNUnet are still in alphabetadebug. General users certainly wouldn't want to have to click permission for every little thing. Is Joe allowed to see your profile picture? secushare would rather give you the possibility of having profiles for different levels of acquaintance and then the software would help you categorize Joe as a more or less important person with the least amount of pain UX-wise, maybe by guessing how you are interacting with them and how much your friends in common matter in your life. There's nothing wrong with social graph algorithms trying to implement our everyday assumptions in psychology and sociology IF THEY ARE OUR OWN ALGORITHMS, not running on behalf of a company with completely adverse interests to ours, but shaped by our own needs and running on our own devices. > > > Any future architectures should make sure that the spam message doesn't > > > even > > > reach the recipient to begin with. > > That's what we've been preaching to the advocates of the > > broken Internet for years. Glad you arrived to the same > > conclusions as us. > > Does GNUnet plan to be a network of consent with capabilities? Because right > now its just an open permissionless hellscape unless you turn on f2f but f2f > is hopelessy worse than networks of consent. You are simply not understanding the full picture and drawing conclusions from the lack of detailed knowledge. That's unfortunate. On Sat, Mar 16, 2024 at 06:17:16PM +0000, Martin Schanzenbach wrote: > I found this funny because there is > https://www.youtube.com/watch?v=hKyNqc1p2iw > and https://www.youtube.com/watch?v=GFa77G9HTj0 > > :D Hahaha, that totally nails it. Yes, you can make square bikes work, but they are so inefficient at it, that you're probably faster when running without a bike. Those bikes show how XMPP underperforms for messaging: Yes, you can kludge something totally unsuited up enough until it starts working, but like these "bikes" it will still not perform anywhere as well as something that was designed in the right way from ground up. In computer technology this keeps happening all the time, just think of the ridiculous FAT32 file system that USB sticks are still being sold preformatted with. Never change a running system? Well, the problem is, it isn't actually running so well! And GNUnet is all about not carrying old kludges into the future. > > If Gnunet has rejected it thats good. Sadly secushare seems to still > > want servers/nodes around. > > Secushare is not gnunet. And GNUnet has certainly not rejected the > notion of not having servers. > Of course when you design a service using GNUnet, you could reasonably > assume supernodes (but don't have to). > For example, looking at historical precedence (look at bittorrent or > IPFS), this is not unreasonable. > Relying on such nodes comes with its own problems, of course. Correct, and GNUnet is not the kind of project where someone just goes ahead with whatever goes on in their heads without a scientific examination of the strategic options on the table. On Sat, Mar 16, 2024 at 09:35:31PM +0200, MSavoritias wrote: > Gnunet seems to be taking a lot of right decisions dont get me wrong :) Exactly, and that has something to do with the methods of taking decisions. A single person may have a great knowledge or intuition on how to address certain issues and not notice their blind spots in other regards even though they will in the end decide whether years of their effort will have any relevance for the rest of society. Scalability has proven to be among the most frequent blind spots of developers if they even doubt needing it.
