Modern XMPP project discussion - 2021-02-17

You can't have a user account running both on a real domain and on an onion domain. How are other servers supposed to know which of the two JIDs is the real deal?

But you could expose a MUC domain under an onion domain simultaneously

You could advertise a server's onion domain as an additional s2s connection mechanism, that way Tor-only servers could connect to it. But there's little point to it, because the Onion domain is a cryptographic identity, and there wouldn't be any strong binding of the announcement to that identity.

The idea is to do it for MUC yeah, and maybe some more components later

> purplebeetroot, I’m not sure if https://xmpp.org/extensions/xep-0434.html (also cc @ raucao) is a way to establish that transitive trust in MUC context > so at the very least we’d need some explorative implementations around that and see which bits are missing and how to securely distribute the trust and distrust messages Oh, thank you. That seems to be a good starting point. Do you know of any existing client that has implemented XEP-0434?

purplebeetroot, no

> we should probably have a privacy "team" reviewing stuff.. would anyone here would like to be part of that? I would find this usefull. It could also help anyone who's specifically interested in that topic, to organize with others without needing to find first those that might be interested. My resources and skills are very limited, but I'd be happy to support/join such a working team and see where I could contribute to.

purplebeetroot, good thing is: we don’t need a formal team for that

just go ahead, review XEPs and post your findings to standards@

on the mailing list, when XEPs transition in critical stages of their lifecycle (e.g. when they become an Experimental or Draft standard), there is always a discussion thread where such concerns can (and should and are to) be discussed

Right! Having something like a platform, so that those specially interested in that topic can easily meetup and find each other might still be usefull. A MUC for it could do that job. (while I don't see myself fit for a leading role in that subject, I just make suggestions, rather then just opening a MUC)

purplebeetroot, a formal SIG could be instated if need be, but first there should be a few potential members plus a potential leader.

but that’s not necessary

the privacy discussions are perfectly on-topic in xsf@muc.xmpp.org, where chat discussion re protocol standards takes place

larger discussions are better held on the mailing list for a broader audience though

It is. But there you'll will regular encounter people that react with attitudes similiar to: - just fork it - that's not important to XSF - discussion on our openess to non-white cis dudes is offtopic - you should not talk about it, if you can't implement it yourself or pay someone to do it for you - this is a rare usecase, we should focus on what we believe what's app users want - don't bring up critism here, because we are volunteers - our resources are so limited, that we better focus on something else In my opinion is this noise that can be avoided by having a seperate communication channel. I might be wrong and over reactive to some patterns I observed in that XSF MUC. ✏

srsly, race, gender, or anything else regarding people's identities and not standards work, has absolutely nothing to do on a standards list or channel

and yes, if you do not want to or cannot contribute actual standards work, then everything you say on there is wasting the time of a volunteer who can and will do it

there's nobody keeping you from creating your own channel for whatever else you want to discuss, and where you can invite people to

you will be the one making the rules for that channel

it sounds to me like you want to discuss user experience a lot, and i think that would be much better achieved by contributing to design and UX work for clients

it is true and unfortunate, that a lot of open-source software developers don't care enough about design and UX, so that's probably one of the walls you already ran into

i think this channel/project is relevant for UX, too. so it's probably not the worst place to discuss general UX issues in my opinion

Yes, but as was said before, the XSF is the place to discuss security and privacy implications

sure, just trying to help with clearing up what standards bodies are for. "non-white CIS blabla something something" is not it. but culture, economic background, hardware, etc. can all be important factors in considering UX

btw, the W3C actually does have a security WG which reviews drafts before they can become recommendations IIRC

definitley a model that exists

because security is oftentimes requires such specialized knowledge that not every spec author can possess

s/definitley/definitely

Yes, this is why XEPs have a Security Considerations section, and it would be great if people would read and contribute to the discussion.

👍️

raucao, I don’t even know what you are ranting about

then you're probably missing channel history

I am not

btw, i am not ranting at all

i'm trying to help a person who was saying their contributions aren't valued in certain places

and that he was shut down

where was i ranting?

> srsly, race, gender, or anything else regarding people's identities and not standards work, has absolutely nothing to do on a standards list or channel well, it is not part of standard work for sure, but if you want to not end up with the same people all over the org, something need to be done about it

that's not a rant. that is just stating facts to explain why someone is being shut down when being racist and sexist on a standards mailing list

you're being racist for saying that all white cis males are "the same people" btw

i do not appreciate your discrimination or considering race and gender to be imporant for anything

omg

That is the dumbest thing I have read today, thank you

lol

explain how race is relevant for a protocol discussion if you can

or for anything for that matter

i'll wait while you'll do mental gymnastics and try to form a resemblence of an argument

For a protocol discussion it isn’t, for a healthy organizations made of people, well, it sure is

there you go

And it so happens that the XSF is made of people, who write standards

the latter is also a pure assertion, but the original point stands

purplebeetroot, the XSF is aware of its lack of diversity (or some of us are, at least), but we’re lacking people who have the motivation and plan to change this. I think this is not due to them being hostile, but (speaking for myself) not knowing what a viable plan is, due to lack of knowledge in that field.

I am also fairly certain that many people will not be able to communicate that clearly, making it come off as dismissive.

purplebeetroot, the XSF chat room is not concerned at all with what "app users" want; valid use cases can be brought up and discussed independent of a specific app. Mind that XMPP is more than just chat, if we only cared about chat users, it wouldn’t make any sense.

same for just fork it really.

the resources argument will *always* stand.

The XSF as-is is already somewhat of a club of people who have know each other for years and have a whole lot of things in common, this is especially visible at summit (and those people work a lot, advance standards, and are very competent, that is not the point I am trying to make)

purplebeetroot, the resources argument will *always* stand. If you only bring up criticism (even if it is senisble and applicable), it only binds peoples time who don’t have enough time anyway. So if you want change, you’ll have to drive it yourself. Just "filing issues" and reminding everyone about them periodically is not going to cut it. That’s how it works in a volunteer run organization, unfortunately.

But that can legitimately be seen as being passively hostile to newcomers because they do not have the unwritten codes & rules to behave as expected, and yes, that is a problem for a standards organization

(and I am not saying I have a magical solution for that situation, but dismissing a way of stating the problem does not make it go away)

purplebeetroot, this is not to be dismissive of your list (I am aware that I did one or two of those myself, but see the point re communication); I want to clarify the background and actually encourage you to step up and do things. ✏

(Also most of the people are stretched thin and do not have time for other additional unpaid work)

(if they ever wanted to)

everyone in the XSF, I presume, has learnt the lesson "you have to pick your battles" the hard way

I for one picked my battle to be "I want free, open, trustworthy instant messaging to be available for anyone, without the data going through silos".

regarding my consciousness, I feel like I’m contributing to the betterment of the world, and I’m investing a lot of time and energy in that. that also means that I can’t invest the same amount of energy in other causes. I try to not actively make things worse regarding e.g. gender equality, but noone can expect me to put the same energy in that cause as I do for the battle I picked for myself.

mathieui: i thought you wanted to explain why you insulted me earlier? calling someone dumb for simply stating that race and gender should be kept out of standards discussions, only to then go on and explain why you yourself are keeping it out of standards discussions, is pretty darn hypocritical. i do appreciate that the rest of purplebeetroot's feedback was addressed in detail however. thank you!

(and no, you don't have to do it now. i appreciate the diversion)

it's a difficult topic, which is why i think you should consider not insulting people over your personal sensitivities when someone actually does touch it in a way you don't directly agree with

thanks

raucao, I did not insult you, I stated a fact, that this is the dumbest things I read today, but even smart persons can say dumb things! Now if you want I can tell you that saying "telling people they are cis white men" is racism is utterly stupid (and also part of alt-right discourse), because that is name-calling at best, but if you feel you have ever been discriminated for being a man in something that really affects you, like access to healthcare, housing, or a job (for this

particular reason)

then that would make sense

but otherwise you are just offended for no reason whatsoever

aaaand you checked out of logic again

good bye for now

lol, fuck off you racist

and I do not waste time with people who believe in sexism against men or racism against what people in occidental societies either ✏

srsly

not cool

if you think you can insult and disrespect people because of the color of their skin, you are simply a racist asshole

mathieui, okay, I need to stop you there.

there definitely exists sexism against men.

I know people affected by it

it is not as widespread, mind, but it *does* exist.

jonas’, I am not saying you cannot be discriminated again as a man (for being a man), that can certainly happen

but I only consider structural racism

okay, that’s *probably* fair

I’m not deep enough in the matter to know when it starts to be structural

maybe be a bit more differentiated in a statement like the one above then, because especially in such a situation like here it’s important to not make these blanket statements

Ge0rG, why would other servers have to choose "which" is real if both exist? just like mail aliases you can send/receive emails with different addresses mapping to the same mailbox, there's no reason we can't do that over XMPP :)

Ge0rG, discovery of keys (eg. onion public key in this case) is out of the scope or supporting vhost aliases, though it's an interesting problem. current status quo is operators sign a list of onions with PGP (alla riseup), and use HTTP headers to let browsers know of an upgrade.. a much better way would be something like the GNU Name System to act for both name resolution and public key resolution, but that's yet another topic ;)

southerntofu, no, it’s not that easy

there’s no such thing as an inbox in XMPP

not any which is separate from the address anyway

purplebeetroot, maybe xmpp:privacy@joinjabber.org?join could be a place to get the discussion going? :)

> > btw, i am not ranting at all > i'm trying to help a person who was saying their contributions aren't valued in certain places > and that he was shut down > where was i ranting? Shut up miss gendering me. No you're not helping me, you're validating my critism by reproducing what I see as toxic working culture. And yes internalised racism and sexism does also matter to the development of open standart, because if not, you simply have a bunch of white cis-males that make it uncomfortable for most/many others to join.

southerntofu: the lookup from xmpp domain to serving host is done via SRV records. You can't usefully lookup SRV over Tor. If you could, you still would have no guarantee that you connect to the authentic server.

purplebeetroot, see, that attitude there, is not helpful in changing things

purplebeetroot, getting people to change for the better by blaming them is... rarely helpful

("you simply have a bunch of white cis-males that make it uncomfortable for most/many others to join." is what I’m talking about, not your interaction with raucao)

raucao, i hear you when you say XSF is the place to review security implications, however given real-time chat reactions of people who are exhausted volunteers, and given that writing a detailed email with formulated criticism takes a lot of mental energy, i can see it as a good solution to have an in-between space where short-lived debate/questions about privacy/opsec can be asked which can lead to more formal review :)

to be fair, i did not suspect the W3C had a security WG given all their many (obvious) failures at designin privacy-friendly standards.. but yes in my view it's important to have a security team, not necessarily because they're so much more skilled, but only because they are not dozens of hours deep into your own spec/work and can review/criticize from an outside perspective (focused on security)

raucao, sorry the discussion derailed greatly, but technical concerns can never be neutral, and we live in a deeply racist/patriarcal society where technology has helped maintain and foster this state of things (you may ask questions about IBM/Bayer/Monsanto/Thalès/BAE...) so no it's not unrelated to protocol/standards, concerns of social justice and who the software's empowering/dispowering is really valid argument

jonas’, you may be interested to checkout how the Tor community operates, they are (to my knowledge and from what i could see) a rather inclusive community where people are not judged solely on technical skills, and where people from different cultural background feel empowered and a sense of belonging

(in fact, nobody has "knowledge in that field", most people who sell "inclusion seminars" and whatnot are just scams, but reflecting on our own privileges and setting up gateways to enter the community without resembling everyone else is always a good way to go)

southerntofu, sorry, "please see this and there" is not going to cut it with undertimed volunteers

> purplebeetroot, getting people to change for the better by blaming them is... rarely helpful And how is your reply helping in that regard? You blame me for articulating anger for sexism that was explicitly directed towards me, as a behaviour that is bad, because it is ineffective. What are you doing to counter sexism that is part of XSF? In which way do you believe is your reply helpfull for those effected by sexism, rather then a justification of the status quo?

purplebeetroot, sorry, I did not want to blame you. I wanted to show you why your statement, in my view, was problematic and how to improve it

no harm intended, sorry if that did hurt you

jonas’, yeah, sorry, I did not expect "white male CS engineers from europe & US show some form of cultural homogeneity" to be controversial (anyway that’s the last of me today on that topic, and I’ll retract the "dumbest thing today" part as I have just opened twitter)

jonas’, i agree with your criticism of valid involvement.. however i believe reporting issues is a valid contribution to a community, and a healthy community should embrace valid criticism, not disregard it.. i understand this is harder when mental energy is scarce, but it's very important for potential future contributors to feel welcome.. i'm not going to write a single line of code for a maintainer who dismisses my concerns, i may take days learning new things to come up with a patch if the maintainer is friendly to criticism

purplebeetroot, you might’ve also missed my clarification: I was not criticizsing your exchange with raucao, but your statement about the XSF in general.

purplebeetroot: the very line before i accidentally said "he" is this: "a person who was saying their contributions". clearly i'm making an effort to use neutral language. sorry for failing in the next line. i come from a native language that is gendered for neutral nouns, making it more difficult in general, but especially in the heat of the moment. a simple "i'm not he, please refer to me as [insert whatever you want]" is sufficient to make me use a different pronoun.

southerntofu, agreed, issue reports need to be taken positively.

but only if no hard expectations are attached to them

and that’s what I often miss on the side of the reporters.

jonas’, there may be resentment against men and/or white people, but nothing we could call sexism/racism, or as mathieui said structural oppression.. "structural" as in the society is ordered around segregating/oppressive principles and materially-speaking one side has way more privileges. which is not to say all middle-class white men have to be bastards their entire lives, but higher level of privileges tends to decrease the capacity to empathy (there's real studies on that). so for whatever reason a white man may be resented, there is no structure in society making sure white men have more difficulty for housing/jobs, or have more chances to end up in prison (white/brown people commit just as much crime, but white crime is less reported and even when reported is rarely punished in the same manner), etc..

jonas’, establishing a mapping of two JIDs to a single inbox shouldn't be hard..

southerntofu, that’s easy. The transmission side is harder

Ge0rG, once onion discovery is achieved (whether with manual mapping alla OnionMX or with a well-known discovery mechanism) .onion doesn't need to read any SRV because .onion resolve to a revese proxy on the server which will serve ports 5222/5269 (without TLS on that virtualhost) and the guarantee is embedded in the onion public key itself (the onion name is the fingerprint of the onion public key)

southerntofu, and thanks for clarifying the "structural" side of things.

raucao: ok, fair enough. I might overreacted in this particual case then. Thought reason for my harsh reply wasn't just based on the accidental miss gender, but you claiming that racism and sexism is offtopic...and then continuing to explain why my points are invalid rather then tryn to understand.

southerntofu, I’d like to add that to gain support even from the privileged ones, it might still be sensible to acknowledge their struggles.

southerntofu: there is a lot factually, provably wrong in what you said, and my entire point is that these things have to be discussed in groups that try to solve societal problems, not technical ones. i have literally travelled the globe for 10.5 years straight to date, and about half of the time in non-predominantly-white countries. i think you're very wrong, and i think this is entirely the wrong place to discuss it

in the end, there will always be a purple dot, and the subjective experience matters

jonas’, would you be interested if i compiled some interested resources from eg. Debian/Tor about their strategies for inclusion and community-building? i understand you may not have the time to review those yourself :)

southerntofu, I would be interested, but I cannot promise anything resulting from that regarding the XSF specifically ✏

(as I’m not an XSF board member, nor interested in becoming one, as I am more focused on the technical side of things)

southerntofu, that’s out of scope for a XEP, as it mainly concerns UI/UX :)

but it might be in scope for modernxmpp

welcome down here, it’s fun

jonas’, why would transmitting with several aliases be hard?

southerntofu, so first of all, right in RFC 6120 it says that on a client-to-server connection, the server MUST stamp the @from attribute (the sender address) with the address which is associated with the stream

i mean some servers expect a message from tofu@foobar.com, others from tofu@foobar.onion.. some servers may expect both for different clients of theirs

which means that to stay within RFC 6120 (the very foundation of XMPP), you have to use separate streams

at which point it’s most sensible to use two different accounts.

why? i don't understand why a stream should have a single address?

because that’s how it’s defined in RFC 6120

changing this would require changing every single piece of XMPP client and server software out there ✏

it makes sense to keep things simple

i mean yes i understand that having a unique identifier for a resource is useful.. but having different representations for this resource does make sense, no?

jonas’, no only the server changing this would have to do anything..

southerntofu, many clients don’t set @from because they rely on the server doing it

(because it’s much simpler than passing the correct address around the entire codebase)

soo... yeah.

lt's take example of the simplest approach, mapping .onion vhost to a DNS vhost.. my server S1 knows it can be reached on S1.org and S1.onion (i'm C1)

it requires touching all the softwares.

you are C2, and foobar is C3

C2 adds C1@S1.org, my server acts as usual

> southerntofu: i think you're very wrong, and i think this is entirely the wrong place to discuss it You are basicly saying, that because you are mostly white-cis dudes, it is important to keep a working culture that is non-welcoming to those that differ from that. You can only change a working culture by either reflecting on it and changing based on that or top-down command. Since top down command is not suitable for such a community, what else is there, beside reflecting, learning and adabting accordingly

C3 add C1@S1.onion, my server will translate the to="" field in subscribe request, from S1.onion to S1.org

(clients would also have to distinguish the @to address on inbound messages, which they most likely don’t even look at today, because why would they; they know that their stream only has a single identity)

so when i C1 send a message to C2, message is sent from="C1@S1.org", but when i send to C3, it's sent from="C1@S1.onion"

southerntofu, okay, so the server would be keeping a mapping?

YES :)

for each possible destination address?

the question then becomes: from which address are messages sent to destinations which are not part of that mapping yet?

e.g. when you send a subscription request to a foreign user

jonas’, this remains to be seen.. i'd say yes for every destination address, with a preference for DNS connection, unless you add an onion contact in which case it would be sent from your onion JID

why DNS connection fallback ? for retro-compatibility with servers who are not federated over Tor (i.e. > 99%)

that’d mean specialcasing .onion, which is ... not sometihng I’m fond of in a generic protocol but may be worthwhile if we consider Tor usage the only usecase for this

and also because then we can add new mapppings in the future for .i2P for instance

(please don’t make it sound as if Tor is the way to go for everything, thanks)

no Tor is just one crypto-secure transport, there are many others and i think a protocol should support all transport mechanisms available, then let implementations and server operators decide on their own usecase

jonas’: you might be able to cheat the mapping by routing all stanzas directed to a .onion JID from the respective local account .onion JID instead of the clearnet JID

Ge0rG, that’s what southerntofu just said :)

southerntofu, Ge0rG, actually, that starts to make a lot of sense

Sorry, I'm still catching up

jonas’: I still think it doesn't make sense because it doesn't give you any benefit over .onion SRV for the clearnet xmpp domain

conceptually, this would treat *.onion as a separate network with separate (but bijectively mappable) addresses and the mapping would happen automagically on the server side

also having a clearnet server with an .onion address leaks its identity to LE

purplebeetroot, i don't think that was his intention but i see your point. if you feel like XSF is not very inclusive and newcomer-friendly, maybe try joinjabber.org? we explicitely try to be those things, and while i can't speak for everyone, i'm happy to receive criticism :)

note that AFAIK raucao is not an XSF member, nor is modernxmpp an XSF project

so please don’t take what happens here as "the XSF did that"

Ge0rG, the threat model for onion services is rarely to hide the server, it's to promote secure name resolution with transport security tied to the name (eg. DNS + DANE all in one)

Right!

also telling the white cis dudes that they are doing it wrong because they are white cis dudes won't improve anything.

I need to step out and do some work now

regardless of which subset of white cis dudes you address.

Tor explicitely supports this usecase with what they call Single Onion Services, i.e. don't do any hopping on server side (i.e. only 3 hops to reach server) so connection is faster but has onion security properties :)

southerntofu: well, tying the user JID to the .onion domain will solve those two issues. But do you still need to have a clearnet JID in that case?

Ge0rG, running an onion-federating Jabber server is the easy part.. people have been doing this for what? 8 years now?

the "hard" part (not too much) is to map the two virtualhosts together

southerntofu: onion federating is again different from merging JIDs.

southerntofu: so why would you want the latter?

(eg. you can use your onion address to federate with onion folks, and your DNS address for other cases)

^ for this reason

Yes, but why not having two different JIDs? Would also give better opsec!

Also how is that more useful than s2s to the clearnet domain over onion?

currently it's possible to have either: a DNS address (but then servers federating with you will need to operate over DNS), or an onion address (but then servers federating with you need to operate on Tor)

i'd like to have both :)

Ge0rG, well using Tor without .onion does not fix DNS/BGP security, an exit node may be subject to active attacks (and they often are)

.onion addresses on the other hand provide secure name resolution and transport security at the same time, that's why many people use them to expose user-facing services

southerntofu: can't you do TLS over Tor, to ensure the server's certificate identity?

> You are basicly saying, that because you are mostly white-cis dudes, it is important to keep a working culture that is non-welcoming to those that differ from that. that's a gross misinterpretation of what i said. also i'm not a member of said group and you're assuming my race and gender without asking

Ge0rG, you can and we do, but it means placing trust in the CA mafia who are known to be untrustworthy.. i understand why we daily make the tradeoff of DNSSEC+TLS (with browser CA) however i appreciate that other projects are coming up with alternative solutions (i2p/onion is one example approach, GNS+Dane is another even more interesting)

i simply believe when developing protocols/applications we should make sure all the moving parts are interchangeable to be future proof.. eg. hashing algorithms, versioned protocols, or in this case swappable naming/transport

southerntofu: fundamentally, I think that XMPP is the wrong protocol to run over Tor, because there is no useful binding between JIDs as the routing and identity mechanism and private keys.

i believe there was a talk from Our Networks (a community networks conference) called "Protocol tactics" addressing such concerns :)

Briar is using Tor identities for users, which is a significant improvement on that front.

But you probably know what they say about Zooko's triangle

Ge0rG, this is barely a JID concern.. having aliases for vhosts is an interesting property, but considering Tor is barely a concern for XMPP, it's just a replacement for DNS+TLS to establish the TCP socket to the server :)

southerntofu: having aliases in XMPP would be a significant change of the basic protocol

Ge0rG, fuck Zooko's triangle, GNU Name System has proven by taking a different angle (eg. hyper-hyper local root zone) we can achieve maximum user-friendliness and security

(sorry i didn't mean it in an offensive way :P)

southerntofu: I tried fucking it, but it fucked back. So please stop the profanity and try to convince me with arguments instead.

I haven't encountered a proposal that would actually solve the triangle, only some magic handwaving from some cryptocoin shitheads.

but my understanding of the XMPP protocol is that a Vhost Aliases XEP would not require core changes to the protocol.. a server MAY have different vhosts serving the same accounts (maintaining an internal mapping so that clients only know of one address, to preserve backwards-compatibility), while other servers MAY federate with each or both of my domain aliases without even knowing they're the same one and that wouldn't be a problem

southerntofu: well, you'd have to rewrite the server implementations to achieve that, but yes, it would probably be possible.

the only way I see to cheat around a foundational rewrite is if it's a 1:1 mapping between clearnet and onion, which can be achieved with a "simple" mapping rule on the s2s side of things

only weird stuff may happen if a client tries to add my two addresses in their roster, in which case my server would probably reply that we're already subscribing to one another.. it may confuse the user a little but not too much because the local parts of the two JIDs will be the same so..

Thing is that there are expectations of symmetry in replies to things everywhere. If you send a query from A1 to B1 and it replies from its alias B2 then things break down. Works in email becasue email doesn't require that symmetry, so you can end up leaking your aliases instead.

southerntofu: yes, the server would have to filter that out

Zash: you'd have a mapping of (local_domain, remote JID) for all remote JIDs

Ge0rG, about GNS you may be really interested in the draft RFC to replace DNS (in backwards-compatible manner): https://lsd.gnunet.org/lsd0001/ short version is https://git.gnunet.org/gnunet-videos-2019.git/plain/ICANN66/GNU_Name_System_-_2019_ICANN66__Martin_Schanzenbach.webm (conf from ICANN)

Zash, yes symmetry would have to be applied everywhere by keeping an internal mapping

southerntofu: the "short version" is 37 megabytes, there is no way I can read that any time soon.

short version is video :P

like 15min

southerntofu: that's actually the long, inaccessible version than.

Ge0rG: I'm wondering how far you get by just keep on swapping (to,from), even if the thing replying has adifferent address

it is! :)

Zash, i think that's precisely what we were discussing

southerntofu: so can you give me a real short version please? two paragraphs at most?

Zash: might work out indeed

at least for exposing MUC as .onion i'm SURE it's entirely possible and not hard to achieve, by having a second component keep track of subscribers to the onion room, and translating to/from fields between onion users and the MUC

Ge0rG, short version: DNS data lives in a DHT signed by public keys, delegation is achieved via public key (not location), and the system is made to be resistant to enumeration, DOS, etc.. while retaining entire compatibility with DNS because existing records are kept and a GNS system may expose a DNS server ; should it be adopted, DNS root will be replaced by GNS root in the same manner, but in any case GNS intends local root to be editable by users so you can save your friends public keys with petnames.. like http://ge0rg/.. which means if you also delegate part of your zone to your friends f2f name discovery is easy.. like http://alice.ge0rg/ would point me to your friend alice in case i forgot her address ; then there's the identity / data brokering algorithms which rely on GNS but is not exactly part of GNS (reclaim:ID)

(i'm sure i'm missing many interesting properties of GNS in this summary, but that should be pretty exciting already :P)

southerntofu: so you say I need to have a public key that I need to tell everybody who's supposed to trust my DNS records?

yes and no: existing ICANN tree would (hypothetically, if GNS is adopted as the new DNS, which it very well may be) still be valid

so you may still have eg. ge0rg.org

whose public key is resolved from root -> org -> ge0rg (in org zone)

southerntofu: yes, so it's the same as current DNS delegation, there is a trusted root providing the keys for .org providing the keys for ge0rg.org

but then from there i could add you to my petnames as "ge0rg" so even if .org decides to revoke their delegation (because you didn't pay, or because of political pressure) i would still be able to access all your records as ge0rg (without .org)

how do you know that the root doesn't misbehave?

southerntofu: but for that you need me to tell you my public key

look, it's Zooko all over again.

Ge0rG, you don't, precisely as is already the case.. but you empower users to define hyper-hyper local petnames for their friends of for directory services they trust

Ge0rG, well there's some TOFU somewhere, though you may build web of trust (or zero-knowledge proof Fog Of Trust, which GNUNet devs are also working on) on top of that, or directory services, or ..

southerntofu: I think the most appropriate reaction is https://www.youtube.com/watch?v=7Twnmhe948A

(can't see the video but wtf is that? :P)

southerntofu: it's hyper-hyper.

southerntofu: but thank you for reinforcing my opinion that there is no way to circumvent Zooko's triangle.

so without doing exactly WebOfTrust, i can publish my favorite zones as delegations in my own, and advertise them on my website/gemlog so that can be used to bootstrap trust

Dat 90s graphis

Ge0rG, it's not circumventing exactly.. but applying petnames on top of crypto-secure global identifiers does break the USUAL UNDERSTANDING of zooko's triangle :)

Zooko's Square?

southerntofu: well, you have petnames that are backed by cryptographic identities that you need to exchange prior to trusting them.

i.e. that we can't have global secure meaningful names.. well we can keep global and secure (public key) while applying another layer of local & human meaningful, and the mapping of the two somewhat defies zooko's triangle

This is *exactly* Zooko's triangle.

Isn't the usual solution to combine two name systems? Is that what they did?

there is no "local" on the internet.

southerntofu: I'm getting out of this now, because I'm convinced this won't lead anywhere, and it's rather off-topic for this place.

Ge0rG, you are correct. it is zooko's triangle.. but applying the two "different" name systems does break the usual conclusion of zooko's

southerntofu: no, it's only hiding the complexity and luring people into a false feeling of security.

</eod>

Ge0rG, sorry i don't mean to eat your time :) i just thought GNS is very convincing on a human and technical perspective (at least compared to the alternatives) and i wouldn't call the MAJOR improvements they implement a "false sense of security" though of course nothing is ever 100% secure

sorry for digression :)