jdev - 2023-12-06


  1. opal removed by moderator

  2. opal

    this is over money.

  3. opal

    you are TOO close.

  4. opal

    the core tenant of foss is freedom zero: the freedom for anyone to use the software. the implied bit is that anyone can ENTRUST that software to have REPRODUCIBLE results.

  5. opal removed by moderator

  6. opal

    that's dangerous and manipulative, and unless you step back or figure yourself out, you have a problem.

  7. opal

    you're allowed to take a break from whatever the hell you need, but get off my nuts.

  8. opal removed by moderator

  9. opal removed by moderator

  10. opal

    this goes to anyone: use openpgp when talking business so i know how to decrypt and *verify* what you typed on your keyboard

  11. opal

    i dont pry further than that

  12. opal

    only idiots do

  13. opal

    nobody else is serious enough for me right now

  14. opal removed by moderator

  15. moparisthebest

    1) What

  16. cal0pteryx

    Oh look, an opportunity to bring up this PR again :) https://github.com/xsf/xmpp.org/pull/1290

  17. Guus

    I don't think there's much need to bring up specific rules to conclude that that was wildly inappropriate.

  18. nicoco

    With XEP-0084 (and pubsub/pep in general?), by having "...+notify" in my disco I will receive avatar (metadata) updates of entities that let me subscripe to their presences. But if I want to retrieve the current avatar of someone in the absence of change, I have to send iq get/pubsub/items node=urn:xmpp:avatar:metadata. Is that correct?

  19. nicoco

    With XEP-0084 (and pubsub/pep in general?), by having "...+notify" in my disco I will receive avatar (metadata) updates of entities that let me subscribe to their presences. But if I want to retrieve the current avatar of someone in the absence of change, I have to send iq get/pubsub/items node=urn:xmpp:avatar:metadata. Is that correct?

  20. Zash

    nicoco, correct

  21. nicoco

    Thanks!

  22. Zash

    You can even subscribe :)

  23. Zash

    No idea what madness that would lead to tho

  24. nicoco

    I thought using +notify == subscribing but apparently not? Or you mean subscribe to data directly?

  25. MattJ

    You can subscribe with an iq

  26. Zash

    I _think_ that the idea is that you are subscribed to everything in PEP if you are roster-subscribed

  27. Zash

    but then +notify filters that

  28. MattJ

    I hesitate to recommend it, because you're in charge of cleaning up such subscriptions yourself

  29. Zash

    at least in Prosody we don't implement it like that (anymore) because it was messy

  30. nicoco

    OK. The thing I'm trying to solve is just to fetch the avatar of the slidge user on startup. I've added "XMPP Avatar to legacy avatar sync" and it works when I change my avatar in gajim. I'm just trying to add "slidge fetch the user's avatar on startup to sync it"

  31. nicoco

    OK. The thing I'm trying to solve is just to fetch the avatar of the slidge user on startup. I've added "XMPP Avatar to legacy avatar sync" and it works when I change my avatar in gajim. I'm just trying to add "slidge fetch the user's avatar on startup to set the legacy avatar"

  32. nicoco

    I think just sending iq get/pubsub/items/metadata on startup is what I need, no need to go further than that :)

  33. Zash

    Does / should the privileged transport stuff notify you of *all* PEP events maybe?

  34. nicoco

    Hmmm I'm not sure we need to go this path? Maybe I don't really understand what category of privilege is relevant here (I start to grasp a few subtleties of chat stuff, pubsub is more terra incognita to me ^^)

  35. Zash

    hm wait, do you still add the gateway to your roster?

  36. Zash

    if so, just send presence with the proper +notify?

  37. nicoco

    yes, the gateway is added to the roster. +notify works but only when there is a "live avatar change", right?

  38. Zash

    you may very well get it on startup/initial presence too

  39. Zash

    don't we have the inverse problem, you get a lot of already received notifications because we don't track what you've seen?

  40. nicoco

    It didn't look like it, but maybe something else what broken? You say I should never need to manually fetch what was already set before the component was added to the roster?

  41. nicoco

    > don't we have the inverse problem, you get a lot of already received notifications because we don't track what you've seen? hum maybe too, but I store the avatar hash and return early if it was already known, so that's fine

  42. Zash

    can't speak for other implementations but IIRC with prosody you should receive the latest everything when you send the first presence of the day

  43. nicoco

    oh ok, so that "initial fetching" might be unnecessary

  44. a moderator removed a message

  45. a moderator removed a message

  46. a moderator removed a message

  47. a moderator removed a message

  48. a moderator removed a message

  49. lovetox

    Yes, you get everything on presence

  50. lovetox

    You only need to fetch the data node if you get a unknown hash

  51. lovetox

    Otherwise you never need to fetch anything

  52. Zash

    Curious tho, do any legacy networks support granular profile permissions like we have with PEP?

  53. nicoco

    I think so, whatsapp avatars are not public by default AFAIK, only your contacts get your avatars. how exactly one becomes another one's contact in whatsapp is a bit mysterious though. In telegram, there is something similar, I think you can even have a public profile pic and a private one for your contacts (to be checked)

  54. nicoco

    In discord, I think you can set a profile pic per "discord server" which would be different than your "account profile pic", possibly only visible to your contacts (also to be verified lol)

  55. nicoco

    FWIW, I think that it would be cool if we could choose different profile pic for each MUC, but if the server supports XEP-0398 then it's not possible to do from a client I guess?

  56. singpolyma

    The server would need to support it, no special client support is needed

  57. singpolyma

    Though I think this kind of thing is only useful as a gimmick

  58. Zash

    We quickly reach the point where "Just use separate accounts" is easier and better

  59. singpolyma

    Yes

  60. singpolyma

    If you have two personas they each need their own addresses, including jabber ids

  61. Zash

    private vs public would be nice tho

  62. singpolyma

    For something like a "use my rpg character in the RPG room" gimmicks it could be neat

  63. Zash

    If we do the thing with urn:xmpp:avatar:metadata#something that wouldn't be too difficult to do

  64. Zash

    Real per-group chat things would be easier with MIX anyway

  65. singpolyma

    Why? Should be the same either way, ferver gets asked for avatar data at the pep node and gives either this one or that one based on who is asking

  66. Zash

    Hm?

  67. singpolyma

    When pep subscribe or +notify etc comes in, check what jid it is from. With MUC bare jid will be of the MUC even which is nice. Send whatever pep contents are relevant to that jid

  68. nicoco

    I agree that it's a gimmick and not vital. Separate accounts are surprisingly hard for non-techies to understand in my experience. "use my rpg character in the RPG room" is exactly the use-case that would make sense for me :o)

  69. MSavoritias (fae,ve)

    seperate accounts is a limitation of not having permission on accounts themselves

  70. MSavoritias (fae,ve)

    if we had a proper permission model and different pictures/personas/whatever we shouldnt need hacks like multiple accounts

  71. singpolyma

    No, you still would because when you give out your address to a contact they could correlate it against someone else who knows that same address as a different persona and thus leak your personas

  72. MSavoritias (fae,ve)

    not with burner/generated jids. it doesnt make sense to give the same address every time

  73. moparisthebest

    That's just seperate accounts then

  74. moparisthebest

    You might mean "creating and managing multiple accounts should have a better UX" which makes sense

  75. MSavoritias (fae,ve)

    no i dont. i mean generated/burner jids. different things :)

  76. moparisthebest

    Depends how hard you squint I guess, but I agree with you it would be nice if this was seamless

  77. moparisthebest

    The annoying part is it might be only *us* that wants this, normal people seem ok with having 1 identifier (a phone number) and giving it out to literally everyone 😬

  78. singpolyma

    When anyone says "multiple accounts" they eean "multiple JIDs". If you do it with burners or multiple logins or multiple tied to one login, whatever it amounts to the same thing

  79. singpolyma

    Just a UX difference

  80. moparisthebest

    Agreed

  81. MattJ

    Except in the case where you want to share one JID between multiple people - I know some JMP users do this :)

  82. singpolyma

    Yes, that's a case where you care about login being different I suppose

  83. MSavoritias (fae,ve)

    Difference in the sense that having multiple accounts is just a patch to the problem of no permissions model. And i includ who can see your jid and what they see instead in that model

  84. MSavoritias (fae,ve)

    Different in the sense that having multiple accounts is just a patch to the problem of no permissions model. And i includ who can see your jid and what they see instead in that model

  85. MSavoritias (fae,ve)

    They work very differently underneath. UX is just part of it

  86. singpolyma

    Just to be clear: you're against "multiple accounts" but pro "multiple JIDs" so we're just arguing about words?

  87. MSavoritias (fae,ve)

    I am not pro multiple jids. I am pro i choose who can see my jid even if i contact them. Or what jid i appear to have.

  88. MSavoritias (fae,ve)

    Which i understand it works differently than xmpp is currently architectured

  89. MattJ

    "Who can see your JID" is not possible to implement in a permission model where JIDs are what identifies what permission model to use

  90. MattJ

    and you need an identifier

  91. MSavoritias (fae,ve)

    Yep i agree. Its a fundamental shift in how xmpp sees identifiers atm

  92. MattJ

    A fundamental shift to "not XMPP" :)

  93. MSavoritias (fae,ve)

    > The annoying part is it might be only *us* that wants this, normal people seem ok with having 1 identifier (a phone number) and giving it out to literally everyone 😬 I have seen a lot of people that have use whatsapp only for people they know because phone number and use something username based for strangers like telegram. Also there is a chinese person here and there that is arguing about how we should make xmpp better for famous people :)

  94. MSavoritias (fae,ve)

    > A fundamental shift to "not XMPP" :) I disagree. Xmpp doesnt need to be tied to DNS to be xmpp. Which jids are currently tied to

  95. MattJ

    What you're describing is a million miles away from XMPP, and I don't think I know of any protocol that does what you describe

  96. singpolyma

    Jids are not tied to dns

  97. moparisthebest

    nostr, kind of?

  98. MattJ

    nostr has *no* permissions model, right?

  99. moparisthebest

    that is, you just have an identifier, sign your messages, and push them to any relays you want your "contacts" just grab your messages from those relays

  100. moparisthebest

    I mean that you have an identifier and it's not tied to DNS in any way