jdev - 2023-08-10

Basically what i had in mind is: You get a contact request as a server or a user. A card appears in the app showing the profile of the user/server contacting you (something akin to mastodon), a message from the user/server contacting you, and a field that shows if anyone from your roster has them in their roster and on what group. This way for example if the server/user is on only one of your contacts roster and the group they are in is "New people, Not sure" then you would know its pretty much unknown if they are trustworthy or not. But if half of your contacts have them in "xmpp developers" group then you know that they are known in the community. For privacy mintigations i was thinking that you can sent the jid, hashed as moparisthebest said, and then your contacts send back a reply with a group/s or empty if they dont have them. This way not the whole roster is leaked. The context i was thinking it of is a consent network with WOT. Where you can consent if the other person can contact you and you share who you trust with your contacts to scale that.

Obviously you query only your contacts for jid's in case it wasnt obvious. Otherwise its a massive privacy hole. ✏

And its meant to be used in a WOT/friend to friend context so it wouldnt even make sense to query everybody.

I'm not sure I even want people on my roster to have that ability

yeahh, that's basically arbitrary contact probing, I do not like that.

I did initially think of a reputation/rating system but i dismissed it almost immediately due to it being horrible

The problem I am trying to solve at hand here is: How do I know I can trust the person that is contacting me?

My other thinking would be what if the circles in this case are seperate from the roster. But I dont know if that makes much sense either since it duplicates the roster anyway :/

"you can't"

otherwise, something like muc-invite-token but for contacts?

You cant make sure they are trusted you mean? But if you know your friends trust them you can have more confidence in it.

You obviously cant be completely sure ever

step-by-step scenario where A wants to add C as contact via B as mutual friend: - A asks B for contact info of C - B presses button in client to forward contact info of C to A; client generates a "voucher" token which is forwarded (hidden) alongside the JID of C - A's client sends presence subscription including voucher token to C. - C's server (or client) asks B whether the voucher is valid - B confirms

Hmm so like a introduction system. That sounds interesting

xmpp:c@domain.example?voucher=.. could even be part of the URI, we already have such a thing for IBR ✏

Of course the issue here is that it restricts new people unless they already know somebody in your contacts. But that can probably be a setting where you allow contact requests from everybody

but that's true for the other system, too

The other system just gives the knowledge if somebody has the person contacting you in their roster. Its a reccomendation/warning.

MSavoritias (fae,ve): but also a privacy nightmare

Well if you get hashes only, from your roster only, and you only send back a group name. I dont see the privacy issue personally. I mean one thing that can happen is somebody DDOS you with contact searches. But you could rate limit them pretty quickly. And finding all your contacts is a matter of chance. Plus you can even restrict who sends you queries to specific circles.

But i can consider the voucher idea too

Or even as an additional thing

Or maybe even a setting either way where you opt in 🤔

I was also told an improvement would be to have it not return who has it in their contact list. just that it is in somebody's specific circle.

If it's opt-in then, fine

yeah it does make more sense. I think making it opt-in, restricting the queries you get to be only from specific circles and not reveal who has who in the contact list is a good first step.

for this. the voucher also is a nice idea.

provided the voucher extends to servers that is

MSavoritias (fae,ve): I do not like the idea of publishing my roster group names to my contacts

and JIDs have rather low entropy (albeit better than phone numbers), so hashing only helps so much

Well hence the opt-in part.

right

I dont know if i will have JIDs per se. Because my app will be based on gnunet with no dns.

At least the current one. Pretty early days in my reading

Will make a note of the entropy concerns though

"- B presses button in client to forward contact info of C to A; client generates a "voucher" token which is forwarded (hidden) alongside the JID of C" < I'd rather not have B send C's JID without C's consent first

The voucher should probably be generated by C

(or not generated, if refused)

you can't prevent people from forwarding PII

Sure you can't prevent that, and I don't mean to

I'd still want a protocol for this to include consent. And evil actors can skip it, whatever

They don't need this protocol to send JIDs anyway

you mean that the person B that is giving the contact details should ask permission from C to do so in a protocol way pep. ?

yes

I haven't really thought about it. I guess my answer as C would depend on trust I have towards B rather than A whom I may not know. But I'd still want to be asked first, certainly

yeah sounds sensible. i dont know what i didnt thought about it

I wonder if it'd be necessary to include info in the request to C. What group they're from in B's roster, or.. I'm thinking in asking to get new contacts, A is consenting for some information to be shared. What kind of information would be shared is certainly to be discussed, and displayed to users though

yeah of course. I think the info card i said above is valid here too. At the very least the A person should have a profile, a short message from A and a short message from B

and the group too

Currently roster groups are "just" tags, they're not categories, and they don't contain any info/description. It's only a name (that can be more or less explicit)

Hmm. Also im guessing there is no concept of roster for servers.

So roster groups would have to be extended

There's server buddies

Right forgot about that xep. I will see if it can be adapted then.

One thing I'm not really fond of in server buddies is that there is no tags like account rosters. I can't set varying levels of trust / use-cases. If it gets adopted for one thing in the community then that's it, it won't be possible to use it for something else in this same space. (I'm reading it right, right?)

Probably. Do you have such use cases in mind already?

(asking because it's very probable that I'll be the one who implements it)

It's something I'm planning to do for Snikket. Not Server Buddies in particular, but the concept of trusted/friendly servers.

it should be the same as circles imo. for two reasons of mostly forward compatibility

1. You can give different access and share different stuff with different circles

2. and the opt in system of WOT I described above makes more sense then

Spam handling I guess is the most often cited. You may want to buddy up with servers to accept their list of blocked domains, and depending on trust you want to assign to them that'd either be accepted automatically, or semi- or.. It doesn't have to be handled the same way for all servers. ✏

but yeah it all boils down to different levels of trust and access

Or use-cases. Spam handling isn't the only thing that can be done with something like server buddies

yeah. like another example my server buddies in the friend circle i trust to create rooms on my server.

for example

Just like putting someone into one's roster doesn't mean the same thing for everyone. (Also why it's often hard to use the roster as anything else than a list of JIDs :/)

yeah i would very much like to see that improved

i am personally planning to have a different profile per group too.

thats another reason i want to use groups

> MSavoritias (fae,ve): I do not like the idea of publishing my roster group names to my contacts This is the other thing I was thinking about, I don't have any sensible organization or naming going on in my roster at all, I maybe used to when I used gajim but Conversations/Dino hide this completely But even if it's brought back you aren't going to get a nice "XMPP developers" from everyone, you are also going to get "XMPP" and "devs" and "internet friends" and "J" etc etc, UI for this sounds hard and confusing ↺

"Conversations [..] hide[s] this completely" actually, no! And I think it's ok in C. It can show tags in the roster

moparisthebest, there's also the thing that if there's an incentive to use the feature (roster tags), people may use it more

And yeah not everyone is going to use the same display name and that's probably fine, it's just an indication. There would probably also be a description attached (written by B) alongside the request to C

Not having descriptive names sounds like a social problem though so its out of scope. What you cando is give people the tools. And I think that does a good step in the right direction

Plus you will be able to see that some people have this person in their contacts even if the group doesnt make sense

as i said i plan personally to built a whole lot of stuff by using the groups. like posting to specific groups ala microblog, seperate profiles, seperate rules and blocking and so on

pep.: Conversations shows them but doesn't allow you to set them, so if you've only used Conversations and Dino for years none of your recent contacts have any, but yes, this can be developed

Right

yeah, one of the reason i keep daily Profanity is actually coz i can set and list by group for jid

A profanity each day keeps roster rot away.

XMPP is so easy! Just make sure you log onto your TUI client daily to keep your roster organized 🤣

i have Gateway in me roster and various non-human accounts. it gets abit confusing if i can't group everythin lol

Or just use the search

I also have Family, Friends, Machines…

> Or just use the search yeah true

I hear Conversations 3.0 will give roster groups a new face

sounds promising. cheogram already surfaces it nicely in the ui

MSavoritias (fae,ve), https://snikket.org/blog/state-of-snikket-2023-the-apps/ this sounded a bit like it :)

the circles you mean? yeah thats why i asked :D

MSavoritias (fae,ve): have you done much reading about pet names systems?

> I also have Family, Friends, Machines… What about the overlapping ones... ↺

These are tags so it's ok to put them in many :)

You can have a machine friend if you like

woo!

MSavoritias (fae,ve), I think what you're really looking for is 'endorsement,' which should be willing not passive, i.e. A wants to add B, and asks C (who already knows B) to forward A's JID for B to consider. A would have to know whether C already knows B, which could be automated with a request containing a hash of B's JID sent to selected contacts; a contact who already knows B (C, in this case) would then see a prompt asking "A would like to add B to their roster, are you willing to endorse this request?" which they may agree to (forwarding the endorsed request to B), or reject (without A ever knowing they know B.) Doing it any other way removes consent from someone - would you be happy with me giving your name/address/number to everyone just because I 'trust' them (having a contact on your roster doesn't imply anything, and even if I do trust them in some limited way, that doesn't mean you should in the same or any other way.) Also, what can you hope to learn from a roster group title - what does "Vänner" even mean? Maybe you actually have a group named "Untrusted," but I don't. "It's opt-in so it's ok" is not ok, especially when that's often a silent opt-in.

theTedd, look at the token flow I suggested above.

yes, I saw that and it's the same idea

Ok I didn't have this in mind when I commented on that flow. To me A doesn't know C's JID yet

> MSavoritias (fae,ve): have you done much reading about pet names systems? Not yet. Its one of the things on my reading list. And one of the thing i am looking to use in xmpp client pottentially. And write a xep if none exists. ↺

One of the aspects i am looking is not to have register a domain as a requirment that is. ✏

among other requirments that is

> One of the aspects i am looking is not to have register a domain as a requirment that is. Tor onion addresses fixes this ↺

tor has problems by itself though. like low speeds.

But like, maybe a few hundred milliseconds added delay? That's nothing compared to for example matrix, which people use without complaining

i would like for my client to have calls though. plus gnunet has a petname system on top. which tor doesnt

You can do all XMPP over Tor but do calls over clearnet

theTedd My target group is basically a safe spaces environment. Trans People, Black people, minorities and such. Where there is a need to know who the person contacting them is and also there is a high trust in the group. UX wise I was thinking of dumping every new person in an unknown or new group and it could be moved by the person using the app elsewhere.

Talking about it some more im not sure how much the token flow makes sense for contacts. because in your example not you but the other people will end being spammed with new requests

and im not sure in what situation exactly you know the person, but you dont know the person enough to ask them for their jid directly

> My target group is basically a safe spaces environment. so people should be trusted into the group by some consensus, not by individuals on a one-to-one basis?

What I imagine the group scenario UX wise would be: There is a Safety Settings where you can pick if you accept unsolicited connection requests. And on top of that how many other people need to have the person requesting contact with you in their roster so that its not automatically rejected.

the difficulty there is for newcomers who don't yet know anyone

> > My target group is basically a safe spaces environment. > so people should be trusted into the group by some consensus, not by individuals on a one-to-one basis? exactly. of course you will have the choice to be "unsafe" where you can be contacted by anybody-anywhere. But by default there shouldnt be.

> the difficulty there is for newcomers who don't yet know anyone the solution i see here is that some people when they have the emotional and mental health capacity will turn off the safety and will allow anybody to add them. That and groups wont have such restrictions.

on the client level. servers will filter the same way though

> so people should be trusted into the group by some consensus, not by individuals on a one-to-one basis? What I meant is that there should be some (maybe server maintained) group which keeps track of who is trusted (by n>threshold already trusted people), rather than the direct individual endorsements mentioned earlier

> You can do all XMPP over Tor but do calls over clearnet I dismissed that because I dont want to implement two different stacks in one application. Plus it brings a whole of complexity to isolate them. Plus the problem that tor onion addresses are unreadable. I havent yet read the whole GNS or the spritely proposal for pet names though so I will have to come back to you on that :)

Yeah, if you go pet names then unreadable JIDs is "fine" ✏

yeah thats my thinking. I was also looking into DIDs specifically for groups and or JID's. but not sure about that yet

> > so people should be trusted into the group by some consensus, not by individuals on a one-to-one basis? > What I meant is that there should be some (maybe server maintained) group which keeps track of who is trusted (by n>threshold already trusted people), rather than the direct individual endorsements mentioned earlier Doesnt that make things too complicated? What I am thinking is that in the contact request "info card" you can see how many of your contacts have the person in their roster and what groups and go based on that.

the server group sounds like extra work and bureaucracy

regarding the token mentioned earlier i do agree that im not sure in what situation it makes sense and i fear it can DDOS the network with requests and shut it down

You'd still need the server to keep track of who has which contacts; having some kind of a group just keeps it all in one place

also, simply having a contact is not an explicit endorsement of that person

we already store all contacts on the server though don't we? so i assume they can be queried directly if needed.

> also, simply having a contact is not an explicit endorsement of that person of course. but i dont see a simple way of doing endorsement without centralizing it

reputation and rating and such dont make much sense.

if everyone is on one server then that server know, but if you don't want to centralize it..

the flow I see: the client gets a request from A that they want to connect. So the client sends a query to your contacts with a hash of the JID of the person to your contacts and asks: "Who has this JID in their roster and in what group?". At that point the contacts that have opted in and you can query (because you may be restricted) reply with an empty response if they are not there or with the name of the group.

and then the client can present that 1 people has them in friends, 1 in devs, 2 in gaming and so on

and based on that surface the request. Provided the person accepts requests for contact that dont exist in their contacts.

or that appear only once for example

> theTedd My target group is basically a safe spaces environment. Trans People, Black people, minorities and such. Where there is a need to know who the person contacting them is and also there is a high trust in the group. UX wise I was thinking of dumping every new person in an unknown or new group and it could be moved by the person using the app elsewhere. There was some "JID trust" XEP presented a few weeks ago. Allowing clients to know if a JID can be trusted when receiving an invitation, couldn't it be reused for your usecase ? ↺

I dont see how this needs to be centralized in this way

edhelas you mean the XEP of MattJ regarding if the account is old or not? I think they have different scopes imo. It deals with what the server knowns. Not the accounts.

In the end its the role of the one that is building the score to know how to generate its value.

So you could build your own small algorythm

There is no score though here. I just get if the jid exists in the roster of my contacts and how many times thats it.

I will come back with an implementation and XEP though at some point :D

How many trusted others have the contact is a score

275 seems tottally overkill for anything imo

I was not talking about that one, that is kinda the same indeed

> How many trusted others have the contact is a score Hmm. I guess. And the more contacts have them the "safer" they are

but i see it much simpler if I just say this is how many contacts have them in their roster and these groups and then letting the person decide. Instead of calculating a score. But this is arguing implementation details at this point :P

> I was not talking about that one, that is kinda the same indeed i know. it was this one i think https://xmpp.org/extensions/inbox/xep-reporting-account-affiliations.html

my context is f2f or p2p though. there is no server for starters for my app specifically. I should have mentioned it ^^

>> You can do all XMPP over Tor but do calls over clearnet > I dismissed that because I dont want to implement two different stacks in one application. Plus it brings a whole of complexity to isolate them. > Plus the problem that tor onion addresses are unreadable. I havent yet read the whole GNS or the spritely proposal for pet names though so I will have to come back to you on that :) (sadly?) This'll actually be the default unless you do something special, your webrtc lib will bypass tor by default sending all possible clearnet IPs you can be contacted at to your contact Re: domain names, don't even show them to the user ↺

i agree i want to hide them somehow. the identifiers. no point showing a long string to the person. QR codes or shortlinks or petnames do just fine

IPs are not in the library's threat model. Plus GNUnet doesnt use IPs at all.

one of the reasons im gonna write a xep about XMPP over gnunet

That'll be slower for webrtc too then no?

I guess what I'm saying is you can use tor for "free domains and no need for letsencrypt" but can still "leak" IPs for good webrtc calls, you'd probably want to be sure this was known somehow I'm also curious how it'd work with GNUnet though so I'll look forward to that XEP :)

good question. there is a module that allows direct connection to the internet but I dont think it makes sense to use it if its going to be gnunet -> tcp/ip -> gnunet. Assuming both people are in gnunet.

I will read more the docs ^^

Quick question: What is the current way to make profiles in xmpp? Like Mastodon style profiles i mean with links and description and prononouns and such. I see XEP-0006 But it says about vcard so im guessing its obsolete? I also remember talk about vcard vs vcard-temp and vcard4. I see the compliance mentions only vcard-temp. Is that a good feature-proof way for my library? Or are we moving to something else? I would rather move to the new thing now that implement something that is on its way out :P

Yeah, vcard4 xep is the way

this one? https://xmpp.org/extensions/xep-0292.html

why is it not mentioned in the compliance then?

i assumed it would be mentioned at least in the future development part where MIX and PEP Native Bookmarks are

ah right the xep says obsoleting the vcard-temp. well okay then. will make a note. thank you

Yes, that one. I don't know why it didn't make the cut to mention in last compliance suites. Gajim, Movim, and Cheogram Android at least all support it now for profiles so there is some experience out there already

nice. sounds good then

moparisthebest: there's no reason webrtc calls have to leak when using xmpp over tor

just need clients to enforce use of TURN or socks5 for jingle in that case

well webrtc itself may not be able to do that, but shrug

Sure it can, we proxy all the metadata it generates via the xmpp part so we control what we send. Can just drop candidates it generates and not send them