Conferences/Summit 24/Minutes Day2

XMPP Summit 24 Minutes - Day 2

Proposed Topics / Votes

• Nodeinfo2 / serviceinfo / the-federation.info: 1
• Our Process / How council makes decisions: 13
• Make XML schemas great (again)!: 9
• In-client, unified, public MUC search (not disco): 1
• MAM Search: 1
• Opt-in server metrics report: 2
• Device list management: 9
• XHTML-IM2: 16
• "Work Spaces": 9
• Inbox/Unread/Bind2 // INBOX // Reconnection: 19
• Sender-less messages: 4

10:47 - IM-NG

Carbons is aiming at not change how any of the traffic looks on the network, and mangle it on the receiving side so that "it does the right thing" IM-NG tries to use sensible addressing. In a purely IM-NG world, "there would be no exceptions"

Possible current issues:

• Errors being sent to other devices (that is not being done atm)
  • When you reply with an error, flip from/to
  • On the server, if it's to a barejid, drop it as always. Barejid -> server handles
  • On the server, if it's from a fulljid, you route it to the device as well as all IM NG enabled clients (I guess). Fulljid -> route to all resources.

PAM / PEP interaction might be fidly

...some discussion...

Migrating from current rules also seems tricky.

...some more discussion...

Lots of the Carbons complexity comes from MUC and MUC-PMs

Incremental changes proposed: When doing IM-NG, we'd change carbons rules? As we want to deprecate carbons should we rather not depend on it? Yes we should put new rules in a new spec.

11:52 - commTeam ("Lightning talk")

Newsletter

Process for the mailing list detailed at https://wiki.xmpp.org/web/XMPP_Newsletter

• MR proposed each month with collected links and various other topics
• Corrections happen (Thanks to everybody who helps)
• The service handling the newsletter is handled by a third-party.
• Once the newsletter is sent, somebody merges it on the website

The newsletter currently only do curation. Nyco hopes we'll start publishing ourselves

Currently 340 subscribers.

Twitter

1676 followers

.. Lots of graphs .. numbers .. .. Red and green ..

Impressions: Someone has displayed a tweet. Engagement: Someone clicked on the link of a tweet. < This is more important

Mastodon

533 Followers

Not exactly possible to get analytics, which is ok. Feeling is that engagement is a lot better than on twitter. People are retooting/boosting and having discussions around what is being published

Linkedin

Not much visibility, but we are present.

Raise awareness

Raise awareness people!

• Write blog posts
• Meetups / Sprints are good to spread the hype and generally get received really well on social networks
• Organize conference?
  • SCAM members are planning to organise a track at FrosCon
  • Possibly aiming at organizing our own conference at some point in the future
• Recruit proper marketing person?
  • This implies we're all aligned and know who to target. The XSF mission statement says something about this but it doesn't seem like we're all aligned
• There are networks where we are less present (because political alignments etc.?) and this is saying on these networks that we don't exist.
  • Having a community manager publishing content on a regular basis could help this.

Call for SCAM content

13:33 - Inbox / Unread / Bind2

Inbox / Unread

XEP-0430

!!! Disclaimer: 333 read markers here means 333 displayed markers. !!! (when used to track readness)

The current pattern should be the same as MAM. You make a request and you get messages containing a bit of information. That will support RSM bits as well and then you get the IQ result.

Does it interact with MUC properly? The message included for groupchat is not useful as it won't be the last (as you're not "joined" if all your clients are offline so not receiving messages from the MUC).

When taking reactions or other kind of messages (whatsapp for example displays "You have left"). What message do we want to consider as the last one?

• The XEP explicitely says the message included has to be a MAM message.

Unread flag during query? Would allow the server to only send back a list of JIDs to do MAM for (that are not known by the clients, that is not in roster or not bookmarked MUCs?)

What about a list of drafts? Some kind of outbox

Is "Marked" really useful in Inbox. It could be split in its own PEP node.

How do we handle "unread messages"? What is an unread message?

• IQ saying you've read all of these?
• 333 "displayed" Chat markers addressed to the server?
  • Currently makes the id matching ambiguous. 333 works by using a tuple of (sender jid, id) and sending 333 payloads to the server would lose the sender jid making things confusing.

Kev's 3 parts proposal:

• Marking of something that's read (tracking readness, not unreadness)
• You need to know on login what was unrea=d, how many etc.
• Marking something as Read might make sense as a PEP node, so that other clients can track
• And the server could also be tracking 333 going through and magically update that PEP node
• Or publishing directly to PEP if you don't (want to) send markers

Dave's TO-DO list:

• Remove Marked.
• Metadata in a sibling element instead of a wrapper.
• Document client update strategy, using "since" a MAM id.
• Optional messages
• Only unread

Bind2 / SASL

Bind2: new set of rules for binding that would allows clients not declare say: carbons etc. sasl2: generic authentication stuff that would also allow for things like password reset, ....? (compared to sasl)

Does bind2 still have a place or does it need merging into SASL?

Is there any reason why we should give up the possibility to implement bind2 or sasl2 indepentently from each other?

• Not at the moment no

14:55 - XMPP as mandatory standard? (Lightning talk)

Currently trying to push to using XMPP more and more in healthcare (Netherlands) Standardization process is interesting

• One group of people is already trying to push for XMPP in this domain.
• Dutch ministry of health wanted to have more standardisation, starting with email, and will become mandatory in the health care industry (to use chosen standards)
• They're also interested in Interoperability
• Dutch government keeps a list of open standards that are mandatory for government bodies to adhere to when they want to do specific things.
  • It would be nice to push XMPP in there
  • Need some "sponsors" (users) to be able to have a voice

Hurdles:

• Quite a lack of knowledge on instant messaging from various actors in this area
• Being compared to Matrix

Features wanted:

• ??
• E2EE
• Search
• Diffie Hellman!!! :D

Timeline?

• 2/3 months for standards
• Interop testing: end of the year

How can the community help?

• PR showing how great XMPP is
• Maybe a set of features that are required to do federation properly?

We might want to be careful about having a set of specifications mandated by the government. What if they publish a list of things that are not entirely correct? Missing features etc.?

15:25 - Stickers

Requirements:

• Cacheable
• Discoverability of sets of stickers
• Requesting different formats and resolutions
• Publication
• Named sets
• Potention mapping to standard emoji
• Viral - If you receive a sticker you can click onto it and ask that set to your list of sets

Prior arts:

• 0038 - Icon styles; shareable way to have icons in XMPP clients. (Xabber implemented something similar?)

Difference between stickers and custom emoji?

• Custom emojis are used more like a normal emoji
• Distribution method is not the same. Custom emoji are used generally in Slack-like solutions, per-instance. Stickers are used in WhatsApp-like/LINE apps and are complete images

How to handle aggregation?

How to handle retrieval?

• Some clients not supporting $format might want to ask the server to provide other formats?
• No we should define a fair amount of formats for clients to support.

How to send stickers?

• SIMS / Possibly indicating multiple URIs (load balancing, not just http sources etc.)
• We need something to say "This is a sticker", "This is the set it belongs to"

How to retrieve a sticker set? Should the set live on a server (local one? some other?) or in clients?

• A user creating a set could upload it to their server in some PEP node, and that would become the reference for others to download
• Other users could copy it on their server
• Immutable sets? Easier than handling distribution of changes
• Clients should probably copy sets on their server from a privacy perspective -> We might not want to leak to the creator of a sticker set every jids that is receiving their stickers

16:00 - XHTML-IM2 / Rich markup

To security concerns:

• There's a handful of things that web clients need a sanitizer for, so this is not an issue of XHTML-IM
• Markdown parsers also support html and people have used that

..

0394 + fallback seems to be a compromise:

<span start="9" end="15" fallback="*"><emphasis/></span>

• Some people are really set on having a syntax that is well understood by users without having to interpret anything
• This is valid until markdown gets out of fashion and users want bbcode
• Some people really want not to mix input format and wire format