jdev - 2024-02-08


  1. edhelas

    Hi

  2. edhelas

    I'm thinking of adding the Broadcast Channels to Movim and maybe complete Modern XMPP as well with this third option

  3. edhelas

    https://about.instagram.com/blog/announcements/introducing-broadcast-channels

  4. edhelas

    It shouldn't be a big issue regarding MUC configuration, however in BC you can react on messages

  5. jonas’

    edhelas, the latter is an interesting point

  6. edhelas

    And that's an issue with XMPP reactions that are actually messages

  7. edhelas

    Wondering how we could handle that somehow

  8. edhelas

    Actually you also see who read your messages, to get some statistics

  9. MSavoritias (fae,ve)

    this seems basically the announcement channels from telegram

  10. edhelas

    Same feature indeed

  11. singpolyma

    Moderated MUC that allows reactions

  12. edhelas

    Wondering if we could actually have mutted MUC by default also ?

  13. MSavoritias (fae,ve)

    basically yeah with the defaults that you get notifications from every post

  14. singpolyma

    Or alternatively pubsub with only emoji comments I guess

  15. MSavoritias (fae,ve)

    announcements muc as a setting would be nice yeah

  16. jonas’

    AFAIK that kind of stuff was discussed at summit

  17. edhelas

    Would it be possible to filter the kind of messages authorized in a MUC ?

  18. MattJ

    Yes

  19. Zash remembers ... this https://xmpp.org/extensions/xep-0045.html#impl-service-traffic

  20. MattJ

    edhelas, https://pad.nixnet.services/WJm97HA9SJaURGhxNqGOcA?view is my "MUC 2.0" work-in-progress, and covers broadcast channels already, but I hadn't considered reactions so I just added a note about that

  21. edhelas

    Perfect 👍

  22. edhelas

    Looks like i'll work on Stories before working on that then :D

  23. moparisthebest

    edhelas: are stories always "public" or filtered by jid or what

  24. edhelas

    I'm planning to create two PEP nodes, public stories and roster based stories

  25. edhelas

    We could create a few others but for now I'll stick to that two

  26. singpolyma

    Why is it two nodes instead of privacy settings on one node? Having a node per privacy setting feels a bit odd?

  27. edhelas

    Because when you publish a story you can choose if you want to publish it publicly or to your contact, and the XMPP client will just switch nodes

  28. edhelas

    Each node have a different access model

  29. singpolyma

    I guess contacts can send both stories?

  30. edhelas

    Sorry, I didn't get it

  31. Zash

    Similar concept we discussed with profiles https://logs.xmpp.org/xsf/2023-11-29 ?

  32. Zash

    singpolyma, I assume the problem is that you can't select access model per pubsub item, only per node, and that affects all items if you change it. So if you have two nodes with different access model you can publish to one of them and get something akin to per-item access model that way?

  33. singpolyma

    Zash: in current servers. Surely having a server allow per item permissions is possible

  34. Zash

    Anything is possible

  35. jonas’

    at zombo.com?

  36. Zash

    The only limit is yourself!

  37. moparisthebest

    > I'm planning to create two PEP nodes, public stories and roster based stories So for at least public stories it'd be really nice to have optional server support for fetching/storing them for users of that server It would both reduce load on the origin server *and* be more private for the readers of the story, as the origin server wouldn't know which users read it or when or anything

  38. edhelas

    > So for at least public stories it'd be really nice to have optional server support for fetching/storing them for users of that server > > It would both reduce load on the origin server *and* be more private for the readers of the story, as the origin server wouldn't know which users read it or when or anything ?

  39. edhelas

    So no PEP node for the public stories, but another Pubsub server ?

  40. singpolyma

    moparisthebest: i dont see why it's different than the dozens of other pep nodes we arleady have?

  41. debacle

    Just out of curiosity: Can PWAs on Android and/or iOS phones receive push notifications? Let's say, a PWA like Converse.js or Movim?

  42. debacle

    Zash singpolyma I believe, that goffi said, his libervia-pubsub server does permissions by item. Not sure.

  43. edhelas

    debacle yes

  44. moparisthebest

    It's "different" because right now I use XMPP to send messages, obviously the things I'm communicating with need to know who I am, and what I'm saying and when If you are instead publishing public things, that's no longer a requirement, and in fact the publisher *should not* know these things

  45. debacle

    edhelas The "yes" was related to PWAs, I guess?

  46. MattJ

    debacle, yes

  47. MattJ

    Movim supports push notifications as a PWA

  48. goffi

    > Zash singpolyma I believe, that goffi said, his libervia-pubsub server does permissions by item. Not sure. Yes it does.

  49. debacle

    moparisthebest That's progress. TV stations didn't know, who was watching, Netflix does even know, when you are blinking.

  50. debacle thinks, that anonymous PubSub item fetching for open nodes would be pretty cool.

  51. debacle

    edhelas MattJ Thanks! That is very nice!

  52. edhelas

    Actually looks like Apple might drop PWA support

  53. edhelas

    https://www.theregister.com/2024/02/08/apple_web_apps_eu/

  54. edhelas

    🤷‍♂️ typical Apple

  55. moparisthebest

    > moparisthebest That's progress. TV stations didn't know, who was watching, Netflix does even know, when you are blinking. debacle: exactly the kind of "progress" I'd like to avoid in XMPP

  56. debacle

    me too!

  57. edhelas

    > It's "different" because right now I use XMPP to send messages, obviously the things I'm communicating with need to know who I am, and what I'm saying and when > > If you are instead publishing public things, that's no longer a requirement, and in fact the publisher *should not* know these things So basically we can drop PEP open nodes and create a complex system to publish those items on some third party Pubsub service ?

  58. singpolyma

    > Actually looks like Apple might drop PWA support Didn't they just add push last year? Seems soon to be killing it 😛

  59. moparisthebest

    >> It's "different" because right now I use XMPP to send messages, obviously the things I'm communicating with need to know who I am, and what I'm saying and when >> >> If you are instead publishing public things, that's no longer a requirement, and in fact the publisher *should not* know these things > So basically we can drop PEP open nodes and create a complex system to publish those items on some third party Pubsub service ? No? Everything can work as normal except the users server can optionally support subscribing/mirroring public nodes for all it's users

  60. moparisthebest

    Except you would have to give up storing user's read states on the originating server for them I guess 🤐

  61. singpolyma

    Sure, a server could do that for avatars etc if it was 100% confident all users would receive the same thing from the pep node

  62. singpolyma

    Doesn't seem safe generally, but maybe sometimes

  63. moparisthebest

    Well if we implement it then pep implementations can understand the consequences of returning different data per requestor I guess :P

  64. moparisthebest

    Again, not a concern where you are exchanging messages with someone already, but a huge concern for posting blogs

  65. singpolyma

    Dhis only improves privacy if you're on a big public server anyway, and that's the case where a bug is riskiest so it seems not worth it to me, but of course I'm not against everyone doing whatever they want on their own servers if anyone wants this

  66. moparisthebest

    I think this is a case where it improves privacy even on single user servers, you don't get my jid

  67. moparisthebest

    Or, when my clients come online

  68. singpolyma

    You wont get when clients come online anyway unless there is a presence subscription

  69. moparisthebest

    No, still will if the clients fetch stories immediately when they come online

  70. singpolyma

    Client should never "fetch" pep

  71. singpolyma

    It gets subscribed to and pushed

  72. singpolyma

    Except in rare cases like maybe browsing something you don't subscribe to

  73. singpolyma

    You'll certainly never mass fetch on sign in

  74. moparisthebest

    >> I receive a pubsub notification header >> I send a payload request to get the content >> I receive the payload content >> I read it >> I send my server the fact that I read the content >> My other client have the notification header >> My other client get the notification that I read it on my first device I'm going off this from yesterday "send a payload request to get the content"

  75. edhelas

    > It gets subscribed to and pushed Headline without payload, resync some history...

  76. singpolyma

    You're almost definitely not going to be subscribing to stories without a presence subscription anyway

  77. singpolyma

    >> It gets subscribed to and pushed > Headline without payload, resync some history... What like avatar? Does that make any sense with stuff that both expires and changes constantly?

  78. singpolyma

    In any case clients aren't going to mass fetch from non contact nodes, that would obviously be a presence leak

  79. singpolyma

    There's nothing fundamentally new here it's the same as all other existing pep from a privacy pov

  80. edhelas

    I have the feeling that you're trying to fix something that is not broken

  81. singpolyma

    Indeed

  82. moparisthebest

    I could not disagree more, is a story something different than a blog post? Do you give your email/jid to every blog operator in order to read their blog posts?

  83. edhelas

    Since when exploring the Web and exploring the XMPP network is the same ?

  84. edhelas

    Afaik, getting some stuff on the XMPP network requires at least a JID

  85. moparisthebest

    > Since when exploring the Web and exploring the XMPP network is the same ? Only since publishing blog posts over XMPP, that's my entire point, it requires different consideration with regard to privacy etc vs current XMPP usage

  86. pep.

    MattJ, this MUC 2.0, can we also define MSN properly?

  87. MattJ

    Yeah, I'm not sure how nicks will be handled right now, if at all

  88. pep.

    Also I'm curious of the types of rooms you're trying to define, is it going to be all that's possible or will I still be allowed to mix config as I want?

  89. pep.

    Typically I don't want to be stuck in these 3 use-cases

  90. MattJ

    I don't think it will replace all the config, no

  91. MattJ

    More like set sane defaults depending on the use-case

    👍 1
  92. pep.

    Not that I want to play with config if I can avoid it, but I'm sure that won't match my use-case..

  93. pep.

    Although that may complicate the spec a bit, maybe it could be made possible to extend this part too? Add different types of rooms. It may not exactly depend on config but also what you do in there. Just define a "room type" field and let various specs define UX on top of it

  94. pep.

    (similar to pubsub#type)

  95. MattJ

    It's not even part of the protocol right now, it's just the requirements section saying those types of groups should be possible :)

  96. MattJ

    So we'll see what makes sense when the protocol starts to take shape, but I don't see a massive departure from the config system we have today, except better defaults

  97. MattJ

    Possible that a registry of room types would indeed make sense, rather than that weird matrix we have on modernxmpp.org

  98. MattJ

    But not sure how to reconcile that with the existing config options if we support them

  99. pep.

    It's not just config options

  100. MattJ

    e.g. a client could configure the room type as private and then set the actual config to be public

  101. pep.

    It's also the UX around it. What's called groupchat in this spec (what we've been calling groupchats) have a specific goal, they target a group of users, there's specific vocabulary for it, etc.

  102. pep.

    (I give you that this group of user is still somewhat large, limits are grey etc.)