Minutes of the 2018 Summit: Day two
nyco: looking at the trends, all searches for keywords are going down.
ralphm: so the attention to XMPP is going down.
alex: People don't search for XMPP but they search for the products that use it.
Kev: it's too broad a question, what do we mean by shrinking? Do we mean that fewer markets, people or new deployments are using XMPP?
Dave: visibility of XMPP is reducing and therefore new deployments.
nyco: federation is shrinking. Federation is incompatible with many business plans and the "VC mindset".
Kev: Federation is a draw for military and public sector, at least federation within their network.
Alex: in b2b world, customers do want federation.
dwd: there are large deployments and usage of XMPP that people in the community aren't aware of.
ralphm: last night we considered the idea of a conference for the 20th anniversary of XMPP/Jabber.
nyco: mentions hype cycle. Wants people to talk more about XMPP, on social media, at conferences etc. Much about the marketshare, mindshare etc. of XMPP is hidden.
alex: actionable outcome I'd like to suggest... some kind of discoverability mechanism. For example, giving someone's email address and then getting IM address. That way systems could discover IM details.
kev: we regularly recognize that this is a good idea, but it's hard to do with federated systems, so progress doesn't happen.
daniel: I consider Jabber to be the federated environment and XMPP to be the protocol. daniel: we don't have an equivalent term to "email", "web", "cloud". daniel: we can use a conference to gather info on what everything is doing with XMPP.
Ge0rG mentions that he wanted to resurrect the Jabber term for IM. Mentions from chat room that the word "open" is pretty much burned.
Guus: people somehow seem happy with IM/chat not being federated.
Kev: would like to clean up the PlanetJabber feed to not included non-XMPP stuff.
ralphm: PlanetJabber wasn't considered to be about only XMPP but about the people "behind" XMPP/Jabber.
Link Mauve: two points, if we want to reach people who are fed-up, then we need more gateways. Internationalization... I could use XMPP because the French community had enough info in French. I.e. internationalization is important and we can do more. I've been thinking of getting blog posts translated.
paul: Would be good to have name to denote federated network that messengers can advertise being part of.
alex: developers want good APIs and care less about protocol. Must be easy to use. Google FCM support XMPP, gives life to XMPP SDK's and stuff.
ralphm: we've been focusing much on the wire protocol the last years (which makes sense, because XSF is standards body), but to get people to use XMPP, we need to focus more on libraries, documentation etc.
Ge0rG:
- The Jabber name still has strong brand value in Russia and other markets. We probably can bring it back to life with a concentrated effort
- The distinction between "Jabber" the network and "XMPP" the protocol is great, like with Email vs SMTP/IMAP.
- Trademark rules are arcane.
- I want to straighten that and have a "Jabber Software Foundation" to do client/server certification, nice logos etc.
dwd: not enough cycles to set up and manage yet another foundation.
ralphm: also, XSF has license for Jabber, not other foundation.
daniel: traditionally XSF has been reluctant to get involved with library development, don't want to be seen taking sides.
daniel: I don't have trouble selling XMPP, but have trouble selling Jabber (i.e. to end-users). Clients aren't good enough, we need better clients.
Kev: would like to focus on points, to avoid discussion going on forever.
- Planet Jabber
Kev: we have vague agreement that it would be good to post more there, and more about Jabbery things.
nyco: please "clap", "like" etc. on social media platforms. Also add comments.
alex: XMPP is highly thought of and well supported in the Telecoms world. Jabber however is not passé.
- Often mentions of a certification program.
Kev personally is not convinced.
dwd: setting up certification scheme is a good marketing scheme and I don't see it much different to compliance suites.
Kev: one drawback of certifications schemes is that we have to know what we're certifying.
- Jabber roundup newsletter.
4 volunteers. We'll set up an informal comms team.
dwd: we can encourage our own companies that use XMPP to blog about it.
- Better clients
dwd: XSF used to be strictly neutral, this has relaxed more lately. XSF can highlight good software and encourage success.
Kev: XSF and highlight clients that support certain features.
ralphm: XSF is volunteer organisation and already doesn't get to do everything it wants to do.
nyco: don't use chat bubbles.
alex: I wouldn't worry about UI too much. In b2b people use XMPP together with other technologies and the client gets created within a larger context.
jcbrand: would be great to get more general UI/UX guidelines for clients.
Kev: if XSF had money, could commission UX designer to come up with investigate phase (i.e. before design).
Thanos: there's design.google.com
SouL: we could create a page with resources.
Kev: share what makes some messengers better than others.
Kev: what wasn't discussed:
- Discovery of JIDs (e.g. based on telephone number email)
- Translations
- Promoting APIs
- Jabber as a term
- Internationalization
2. IoT
Daniel_W's talk slides: https://www.dropbox.com/s/y1mnc1t8l56khsx/IoT%20Pres.odp?dl=0
3. SPAM
Link Mauve: at Jabber.fr looked at what software spammers were using, what websites they visited etc.
Usual way to prevent them from spamming was to inspect messages (e.g. links, message too large etc.).
We use XEP-0157. Used to share info to server admins. Some admins might not know that their servers send spam.
dwd: some older servers won't be updated to provide contact info.
SouL: are there XEPs for abuse/SPIM reporting?
Kev: yes, XEP-268 (instant reporting), XEP-236 (Abuse), XEP-287 (SPIM markers and reports), XEP-377 (SPAM reporting).
Michal: instead of checking message contents, we checked whether messages conformed to the spec, for example some messages had typing errors, or MUC messages were sent to bare JID.
Ge0rG: just blocking multi-line messages get rid of 99% of spam. For subscription spam we could get far with a captcha from JIDs that we didn't receive or send anything to. Another idea would be a security question that the user defines for the requesting contact.
Ge0rG mentions his manifesto: https://gist.github.com/ge0rg/2e4accf6950821ca45f743fdf587c08e
Discussion ensues about blacklists of spammy servers.
edhelas: I block messages based on the time the messages are sent. Many messages are sent at the same time. So you can check how many messages are sent within a short span of time. The next frontier in spamming is PubSub spamming.
vanitasvitae: we use a captcha for subscriptions, eliminates subscription spam.
4. Discovering features of offline devices
Kev: if you have some feature that requires that all your clients support it, it's useful to know whether they do.
dwd: With something like Jingle, we care if there's at least only one Jingle-capable client around. With something like OMEMO, it's some other value.
Kev: disco is the solution. You do have to define what "all devices" means. We have some examples of registering devices, like OMEMO and Push.
dwd: we want to discover the "staleness" of a registration record.
Michal: when pushing to mobile devices, you will receive info when a device no longer exists. And the push component reports back to the originating server.
Kev: would we want independent registration for OMEMO, Push and the new super/subset feature discovery, or do we want to unify them all?
dwd: unify.
daniel: could resources that stay the same be used for this?
ralphm: wasn't this considered a security risk?
dwd: if client info is published, would make sense to have stable resource.
Kev: objection last year was using resource as use-enterable, but not necessary against it being stable.
ralphm: if when you bind the resource, provide the resource you used last time, the server could still be free to decide what resource to use taking clustering into consideration.
ralphm: trying to gain additional functionality by doing something special in the identifier, instead of the usual way of adding a child element, is not ideal (like Guus mentioned earlier).
Could add namespace element to BIND, asking for a stable identifier.
Kev: whenever doing BIND2, could provide stable id as part of default semantic.
Guus: I'd rather have explicit element instead of having default semantics.
Discussion ensues regarding letting the XMPP server doing disco query to client to get stable resource.