XSF Discussion - 2023-11-29


  1. debacle

    edhelas goffi and the rest of the "social crowd": Is there a MUC for social XMPP similar to the IoT one?

  2. goffi

    not that I'm aware of.

  3. goffi

    I guess for now, here of jdev@ are the best places, the social related traffic is not big (yet?).

  4. debacle

    goffi It's a question about standards: In Jabber we have avatar image (how many standards are there and which is "current" one?), which can be used as "profile image", but social networks (Mastodon, Twitter, Movim) also have a "header image". I wonder, if that is already standardised in a (proto) XEP?

  5. debacle

    Header image is typically much larger than profile image and shown in far less places than an avatar, esp. on an "orginal page" or homepage.

  6. goffi

    Can't we use vcard4 for that somehow?

  7. debacle

    goffi I'm not sure, if we want a large image in a vcard.

  8. Zash

    I'd rather not have any images in vcard4 when we have '84 that can deal with that more efficiently.

  9. goffi

    I was thinking more about a link than the encoded image. Is there any other XEP that we could use for this kind of data? Something PEP based maybe?

  10. debacle

    Zash Can I have multiple avatars with 0084? And $client just uses, what fits best?

  11. Daniel

    debacle, I think the idea is generally that it is the same avatar in 84 and client picks based on format and resolution

  12. pep.

    It's not possible in 0084 to define a role for the image though right?

  13. pep.

    It's just "an avatar" whatever the size

  14. debacle

    Daniel Sounds reasonable. pep. With a specific, explicite "role", it would even be better.

  15. Zash

    0084 or a variant thereof with roles would be nice

  16. debacle

    If somebody has a header image, but not a profile image, clients would try to use the header image as avatar, which gives probably very ugly results.

  17. debacle

    "header image" and "profile image" are Mastodon lingo. Not sure, if they are defined in AP or if they make sense in XMPP.

  18. goffi

    XEP-0084 doesn't seem to have anything to specify something else than the usual avatar.

  19. Zash

    0084 does support URLs, so if you either upload somewhere persistencly or re-upload a thing every now and then...

  20. goffi

    You can use size to choose, but a well-know "role" would be better.

  21. debacle

    I'ld love to see an XMPP solution, not an HTTP breakout :-)

  22. debacle

    0084 + role sounds beautiful.

  23. Zash

    84 but add `#${rel}`, like `urn:xmpp:avatar:metadata#profile+notify` ?

  24. Zash

    84 but add `#${rel}`, like `urn:xmpp:avatar:metadata#header+notify` ?

  25. goffi

    can't we add a `role` metadata? It's stable but not final, and this is a non breaking change (just default to normal avatar).

  26. MattJ

    And what will clients that don't understand 'role' do?

  27. goffi

    business as usual.

  28. Zash

    84 with multiple different images is currently undefined I think

  29. MattJ

    It seems they will likely accidentally use the header as an avatar

  30. Daniel

    I think at least it would have to be in a different namespace

  31. Zash

    Does the format need to be different?

  32. goffi

    there is an example with multiple images: html_redirect_dict = { "actor": "/", "item": "/b/{item}" }

  33. Zash

    As above, I think it's probably enough to put 84 data in a separate node (pair?)

  34. MattJ

    I lean towards a different node too, it's backwards compatible and doesn't waste the time of clients that don't use it

  35. goffi

    sorry for the bad copy/paste: https://xmpp.org/extensions/xep-0084.html#examples-multiple

  36. Zash

    goffi, that is meant to be different resolutions of the same image

  37. goffi

    you mean a new XEP? Fine, but what if an other "role" is needed, we do yet another XEP with a new namespace?

  38. Daniel

    you could design the new xep with role support in mind

  39. goffi

    If we use a new namespace, we can add a `role` metadata this time

  40. goffi

    yes exactly

  41. Daniel

    if you think there will be multiple roles needed in the future

  42. goffi

    I don't think so, but I rather anticipate this time.

  43. Kev

    A different namespace with the same syntax/semantics isn't a particular hardship, is it?

  44. Kev

    I mean, planning for extension that you don't think you need, when there's already a sensible path to extension if you do, doesn't seem necessary to me.

  45. goffi

    it's a new XEP each time, and if tomorrow we need "footer" image in addition to "header" one, I think it's a pity to have to make 2 xeps when we could have anticipated with only one.

  46. Zash

    Beware of premature genericness too!

  47. MattJ

    Add 'role' into the new one, I think it's fine to separate the user's profile picture (which is shown in a bunch of places) from other resources that might be shown on their profile

  48. Kev

    > it's a new XEP each time, and if tomorrow we need "footer" image in addition to "header" one, I think it's a pity to have to make 2 xeps when we could have anticipated with only one. But you just said you didn't think we'd need another role :)

  49. goffi

    for now, but who knows in 5 years. If we had a "role" in the first place in XEP-0084 we wouldn't have this conversations.

  50. goffi

    and it's cheap to add a simple metadata field for that.

  51. Zash

    is it cheap to send that to every current client that doesn't understand it?

  52. goffi

    Why would I send this to client that doesn't understand it? We're talking about a new XEP to extend XEP-0084 right?

  53. goffi

    not modifying XEP-0084 itself.

  54. Zash

    So separate node then?

  55. goffi

    yes, but this type with an extra "role" field to anticipate futur.

  56. goffi

    this time*

  57. Zash

    If you put the role into the pubsub node, you get the benefits of pep +notify

  58. goffi

    basically `urn:xmpp:avatar:data#extra` (or whatever) = XEP-0084 syntax + "role" metadata.

  59. Kev

    You certainly don't want to shove different roles within a single PEP node where you expect clients to not all be interested in the same roles.

  60. goffi

    ah right, I was thinking about URLs, but you can encore with XEP-0084. Would it be possible to have a XEP to specify that we can use `urn:xmpp:avatar:data#<any_role>` once for all?

  61. goffi

    encode*

  62. Zash

    So, what I suggested above then?

  63. goffi

    Zash: yes, but with open suffix.

  64. Zash

    I must have been unclear then, because that is what I was thinking

  65. goffi

    alright, we agree then :)

  66. Zash

    :)

  67. goffi

    ah yes, reading back I've missed the `#${rel}` thing

  68. Kev

    Although just specifying 'and this can have any value' seems of limited use to me, as to expect to interop you need an enumeration of the values to be interested in.

  69. Zash

    registry? :)

  70. Kev

    Right.

  71. Kev

    Although an in-XEP registry seems easier than having a 'real' registry.

  72. Zash

    Sure.

  73. Zash

    Specific recommendations for aspect ratios etc

  74. Kev

    And unless I'm being dense, you could reasonably extend 84 for this, if it's the only change being made.

  75. Kev

    Although a new XEP is also not harmful, and maybe easier.

  76. jonas’

    11:28:27 Kev> Although an in-XEP registry seems easier than having a 'real' registry. wouldn't that require a council round-trip on every iteration?

  77. Kev

    Well, if Council are subsuming the Editor role anyway...

  78. Zash

    Thought: embedded registries in XEPs?

  79. Zash

    Like, includes

  80. singpolyma

    I pretty much agree with the early part of this discussion (multiple avatar images, choose by size) but it's worth noting movim already has an implementation of this and it uses a second node

  81. debacle

    Is there of a (standard?) way, how an admin of a server (admin@foo) can send a subscription request on behalf of a user (julia@foo) to any JID (romeo@bar)?

  82. debacle

    Is there a (standard?) way, how an admin of a server (admin@foo) can send a subscription request on behalf of a user (julia@foo) to any JID (romeo@bar)?

  83. Ge0rG

    no

  84. singpolyma

    since you had it written as (standard?) way I will say standard, no, way, depends on server

  85. debacle

    Thanks!

  86. nicoco

    Edhelas implemented a banner image in movim debacle, I think this is what you're looking for

  87. edhelas

    Yup, it's basically the Avatar XEP, but on another node

  88. edhelas

    Yup, it's basically the Avatar XEP, but on another PEP node

  89. debacle

    nicoco edhelas My movim account has a header image / banner image, of course :-) I want to use it for my future™ fediverse account (based on Libervia AP gateway).

  90. debacle

    edhelas What is the name of the PEP node?

  91. edhelas

    debacle https://github.com/movim/movim/blob/master/src/Moxl/Xec/Action/Banner/Get.php#L17

  92. pep.

    edhelas: "technically" this isn't (standard) legal as urn:xmpp is managed by the xsf. You can do movim.eu:banner (or what was it again?)

  93. edhelas

    Ah, oops, sorry !

  94. pep.

    edhelas: "technically" this isn't (standard) legal as urn:xmpp is managed by the xsf. You can do xmpp:movim.eu:banner (or what was it again?)

  95. edhelas

    Will try to change it, actually that would maybe push me to write a XEP and ask for a proper urn

  96. debacle

    edhelas Yes, a XEP! ;-)

  97. edhelas

    Finishing some stuff before :p Moving to a new house.

  98. edhelas

    By the way I got some feedback today from the NLNet guys, they have a loootttt of requests to process, so it might take a few more weeks for those that are waiting for their answers.

  99. Guus

    I had the same message from NLNet

  100. singpolyma

    Maybe I'm glad I got sidetracked and didn't finish my application 😅

  101. goffi

    edhelas: can you have a look at the discussion earlier today? If you are already using XEP-0084 then you just have to change the node to `urn:xmpp:avatar:[meta]data#header` and we're good.