XSF Discussion - 2023-11-10

I just searched for ever for this page: https://xmpp.org/extensions/ (I know now it's linked from the start page but i wasn’t on the start page)

should we give this a more prominent place in the main menu?

given that xeps is 90% of what the xsf is about

and the fact that the new design is actually pretty good

It's the 'Specifications' button on the front page, and About->Specifications in the menu

I'd propose maybe dropping 'Software' and 'Getting started', add a new 'Resources' menu that has links to Software and Specifications and Guides

And the buttons should probably be spaced apart and identify themselves as for users or for developers, respectively

"Get Started" is very ambiguous, especially in this context

Software can stay imho but yeah I'd get rid of getting started and just put specifications up in the main menu (instead of hiding it in the cluttered about)

I just feel like the top bar/menu is getting a bit cluttered with random things. Maybe if we collapse 'Blog' and 'Newsletter' into 'News'

Software is generic enough (in both title and content of that page) that both end users and developers get something out of this

Sure

> I just feel like the top bar/menu is getting a bit cluttered with random things. Maybe if we collapse 'Blog' and 'Newsletter' into 'News' Yes. I think the entire menu could use some reorganizing. But I wanted to start with some small concrete suggestions

Just replace the whole index with two big links to specs and implementations?

https://matthewwild.co.uk/uploads/screenshot-20231110-1699610642-29670.png

?

MattJ: yes

I'll come up with something :)

Semi related:I would consider Jobs a failed project and either remove it entirely or at least not display it this prominently

Im against removin the getting started page

emus, it's already the most prominent thing on the page

it should be made better. we still lag a good landing for people

yes

If we add everything to the top level of the menu, which is what has been happening over the past year or two, we just end up with a disorganized list of links

Anyway, I'm happy to submit a PR for the screenshot above, or otherwise carry on with my day :)

I don't really have the bandwidth to debate it right now

Yes please submit a PR

yes

Getting started is still prominent on the start page. And if/when we improve 'getting started' we could maybe consider bringing it back to the menu. Imho software and specifications are currently our best pages content wise (and also obviously important) so we should feature them prominently

agreed

but as matt said, people care about products and using them, not protocols. still its our main product too

I am with it, just want to keep and improve getting started

> but as matt said, people care about products and using them, not protocols. still its our main product too I would argue that Snikket and xmpp.org have very different audiences

I think was a different context

and in the end we want people end up in a running conversations, snikket or what ever, but not fiddeling around where to start. just the approach of a landing page I argue ✏

I don't think the XSF can/should serve users directly, but whether we like it or not XMPP is a brand of sorts, and non-developers do end up on xmpp.org, so we should be able to point them in the right direction

So I'm happy with keeping the guide prominently on the landing page

The guide itself is probably something we should work on improving though

I note, without much enthusiasm for arguing about it being the right approach, that most 'technology' sites (be it frameworks or protocols or whatever) seem to approach this in terms of "Used in" in one way or another. So rather than advertising the projects consuming/producing/whatever, they have those in a 'using this technology' section, and keep the main flow about what the core org itself provides.

If we were adopt something similar, I think we would have the software section under 'used in', along with sample deployments or whatever.

I think there's room for some kind of showcase thing, yeah

> MattJ: > 2023-11-10 11:37 (GMT+01:00) > So I'm happy with keeping the guide prominently on the landing page ah, with landing page I meant something like getting started

> MattJ: > 2023-11-10 11:36 (GMT+01:00) > I don't think the XSF can/should serve users directly, but whether we like it or not XMPP is a brand of sorts, and non-developers do end up on xmpp.org, so we should be able to point them in the right direction Well, then we need a different institution, or something at .net

Okay, I was talking about xmpp.org, which I assume to be the main point of entry to the site for people who just did a search for "XMPP"

joinjabber.org, which we already link to

yeah. i dont understand why we have three different places that we propose clients

MSavoritias fae.ve: what's the third one?

plus most xmpp servers have their own reccomendatios

Getting started, Software and?

> MSavoritias fae.ve: what's the third one? joinjabber, xmpp.org and providers ↺

ah software too true

but thats more technical

Ah OK. Yeah providers doesn't recommend clients

They only list which software supports their directory

Which is confusing but not something we can address as the xsf

https://providers.xmpp.net/apps/

i meant this page

> Here you can find all known apps with XMPP Providers support.

Yes

i agree that xmpp.org should focus more on organizations, developers and people wanting to get involved with the standard process. thats it

I'd be OK with getting rid of 'Getting started' entirely and delegating this to join jabber (currently they seem to be doing a better job)

> MSavoritias fae.ve: > 2023-11-10 11:53 (GMT+01:00) > https://providers.xmpp.net/apps/ I think its not a page that is advertised first hand and dont understand why its confusing

yeah i agree. the getting started page in xmpp.org is the reduntant one

>> MSavoritias fae.ve: >> 2023-11-10 11:53 (GMT+01:00) >> https://providers.xmpp.net/apps/ > I think its not a page that is advertised first hand and dont understand why its confusing its linked from the front page. its not that its confusing. more that the getting started at xmpp.org is not needed with all the app reccomendations we already havn ↺

Users dont understand xmpp ids and clients are disconnected

thats why you cannot just sent them to the software page as it is

so what you are saying is providers is meant for app developers and not users? and you want to use xmpp.org to integrate the providers and apps there in a better way for people who want to use xmpp? sure. i was just arguing the other way because providers doesnt look like its meant for devs. it looks like its meant for people to pick a server

Yeah, this has been one of the big confusing things about that project since it began

It's a nice user-friendly website around data that was meant for clients. For example it gives a poor rating to servers that don't support open in-band registration (because it's designed for clients that want to do IBR).

What are the target audience(s)?

First of all, for sure the users are the central focus. But the idea since ever is, that clients provide eithe automatic registration to decent server or have a helpful interface where use can pick based on their needs if they have any known. That never changed and is a core intention. UWPX did a very nice implementation of this back then. So, the core product is the lists we provide. We had the lucky situation that, also for communication purposes, a website has been made around this. User CAN use it, but they should rather have the good expierence out of the xmpp apps. Yes, we also have a lot FAQ for devs to read. We also.have this nice table view, which I think is awesome regardless of the project purpose. We rate closed IBR down because we evaluate also towards automatic registration. If you have switched this off, it obviously is not good to recommend. However, many server have a bad rating because of missing information. Or other circumstance that we don't to recommend this to NEW and non-tech-savvy users. You all here dont need such website, they do. Last but not least IBR switch off and having an unmaintained list of potential good server is not an answer to thrive a federated network. In that regard, I personally risk the blame of putting up an evaluation like this. Its not that we do not document the criteria or raise a high bar. CC: cal0pteryx melvo

Additionally, with the automation setup we have a great instance to overcome all these outdated manual listings etc.. We dont force any dev to use our categorisaton. Instead they can just extract the up-to-date information and do their own filtering. But this is not what developers should spend their time on. And I think in genereal this is a great achievement. (And I don't recommend as we have experienced often that ends up in a non-user focused manner.)

but the question is who is the website for? the providers.xmpp.net that is. i get that the data is supposed to be for clients. and with a focus on people signing up with just a username.

anyway the providers website lacks focus imo. so at all what the xsf strategy is there. (if one exists/needs to exist at all)

MSavoritias fae.ve: You actually complain about its listed on getting stared right? We put it there, because before it linked it manual and outdated lists like in our wiki or the one from jabber.at. no more strategy behind it and was worse before Which focus do you miss? you fire up the website and it will show you suggestions. anything else is a nice extra we added for us or for interested folks without doing any extra works on the file we provide

emus, this didn't really answer who it's for. Maybe the best way is to register through a client, fine. But then someone lands on the *website*, which prioritizes services with IBR.

It's a neat website, I think there is a lot of confusion. If it's a replacement for the other lists aimed at users, it shouldn't use rankings based on what client developers need.

Also not related, it seems in apps you're duplicating blabber.im and UWPX and you also list them in "Archive"

MattJ: The entire project is for newby XMPP users. And that will server in our believe the entire XMPP network positively. Because it improves the quality. I hope none doubts that since ever onboarding to XMPP often is a pain. but in the second row we need developers and servers to help here of course. If noone adapts, then it bare can help. > MattJ: > 2023-11-10 01:34 (GMT+01:00) > emus, this didn't really answer who it's for. Maybe the best way is to register through a client, fine. But then someone lands on the *website*, which prioritizes services with IBR. Our attempt is still coaching maintainers that this is not the only way to prevent spam and keep it open. This is not a good development and we try to compete it.

> pep.: > 2023-11-10 01:39 (GMT+01:00) > Also not related, it seems in apps you're duplicating blabber.im and UWPX and you also list them in "Archive" yes, I was up to fix it already, thanms

I highly recommend you find some random strangers, show them the website (either providers.xmpp.net or xmpp.org) and ask them to send you a message on XMPP

fwiw, and I've already tried to reach out, "The entire project is for newby XMPP users" this is also our goal at JJ (at least part of it?). Happy to do some of the things together if that makes sense to you. We also do need operators to be part of the project and see how we can all make this work / come up with changes in (server) policies and all, and decide who gets to be part of the group.

emus, ^

The way we want to reach this goal may differ though..

MattJ: Well, still, and that should all proejcts have in mind, how do we improve the siuaton for our users. So this is still the focus. Are we a first hand instance to get them writing a message, maybe not. As said we rely on the adaption of the service in the XMPP comunity by the clients for example. but also by the servers in terms of transparency. that the other side of the coin for sure

pep.: yes, we have seen this but we were focussing our resources on all the automation stuff first then we can see how we change other stuff. Our focus right now is to get the list as much as possible automated. That also already lead to many servers moving away from bad ratings or reducing the reasons for it.

I like joinjabber.org and I can imagine a future in which xmpp.org just points end users to joinjabber.org for all their end user needs

For example the 'getting started' Button just leads you there

And then xmpp.org can be focused on developers and spec authors

emus, that's stuff happening on this repo? https://invent.kde.org/melvo/xmpp-providers

In tools/ ?

pep.: yes

FWIW I did do what I suggested above, regarding testing with people, and the result was the Snikket onboarding process. I'm not saying it's the only possibly way (far from it), nor that it's perfect. But there is value in working through and polishing the "journey" of a new user, and not just putting up untested guides or websites with collections of servers/software (even though those things do need to exist).

providers.xmpp.net is a third party project and I don't care how they run it. (although I find the apps section (just the apps section not the rest of the website) confusing. But that's just personal opinion)

jj.o is also a third-party project :P

> Daniel: > 2023-11-10 01:49 (GMT+01:00) > I like joinjabber.org and I can imagine a future in which xmpp.org just points end users to joinjabber.org for all their end user needs > For example the 'getting started' Button just leads you there > And then xmpp.org can be focused on developers and spec authors Folks, what ever the answer in the end is not any website, but a service they just install out of their stores and it works and provides them directly with a good experience.

MattJ, yeah I agree. Tbh I still don't like jj.o's on-boarding experience, but I think that's clear enough from chats in chat@jj.o :)

I'd like something even more focused

emus, sure. The point is how to get them there

pep.: it's better than the current get started page on xmpp.org

> MattJ: > 2023-11-10 01:51 (GMT+01:00) > FWIW I did do what I suggested above, regarding testing with people, and the result was the Snikket onboarding process. I'm not saying it's the only possibly way (far from it), nor that it's perfect. But there is value in working through and polishing the "journey" of a new user, and not just putting up untested guides or websites with collections of servers/software (even though those things do need to exist). And I still would be happy we also advertise snikket in someway under software

I would also be happy to just link that to joinjabber.org and keep all the user-focused stuff together under one "brand"

Thanks :) (for those who are working on it)

> pep.: > 2023-11-10 01:53 (GMT+01:00) > emus, sure. The point is how to get them there We believe an implementation of such a service does

> MattJ: > 2023-11-10 01:54 (GMT+01:00) > I would also be happy to just link that to joinjabber.org and keep all the user-focused stuff together under one "brand" I would be happy that xsf could do somthing not as third party project too. But for sure we should also link to the other onboarding attempts. as said, the providers list is only there because before it was worse.

> I would be happy that xsf could do somthing not as third party project too. Why does it have to be the XSF?

As a *standards* foundation, I don't think it should, or usefully could, be the XSF

We could link it very prominently. So the discoverabilty is there

Though the XSF could of course support such projects in various ways (fiscal hosting, etc.)

And it's an overlap in people anyway

> Daniel: > 2023-11-10 01:51 (GMT+01:00) > providers.xmpp.net is a third party project and I don't care how they run it. (although I find the apps section (just the apps section not the rest of the website) confusing. But that's just personal opinion) I don't get why people argue about parts here that are for documentation and people that are interested beyond and where we want to show application of the project, not guide anyone first hand. What we should argue about is how to spread its application and lack of server transparency or other weird stuff going around that harm the network...

I would be happy for the XSF site to have a "things using XMPP" section that included a link to e.g. JJ. This seems the right separation to me.

> MattJ: > 2023-11-10 01:57 (GMT+01:00) > As a *standards* foundation, I don't think it should, or usefully could, be the XSF We dont have anything more official. thats why

Kev, I don't think that is really enough to solve the "end users encounter xmpp.org" problem

Kev, technically jj.o is not here to showcase XMPP

> I would be happy for the XSF site to have a "things using XMPP" section that included a link to e.g. JJ. This seems the right separation to me. Put it on the start page for all I care. I mean the fact is that sometimes end users stumble over xmpp.org

It's here to have people get in

In fact I strongly suspect >85% of people viewing xmpp.org for the first time are not developers, today

> , I don't think that is really enough to solve the "end users encounter xmpp.org" problem No, sorry, I wasn't saying that I thought it was. I was saying that I think that's an appropriate level of entwining between the XSF site and the JJ site.

> MattJ: > 2023-11-10 02:00 (GMT+01:00) > In fact I strongly suspect >85% of people viewing xmpp.org for the first time are not developers, today also not good ^^

I'd much rather shove those people to somewhere else that is dedicated to helping them, rather than trying to (unsuccessfully) do that in a developer-focused standards org

xmpp.org: # XMPP Standards foundation We're the body that looks after the XMPP protocol if you're looking as a user, see below ... ## XMPP For users [this page] provides assorted groups offering XMPP for end users.

Would be my preference for how to deal with that problem.

this ^

no

If we must have multiple such groups, I think that's a shame, but I see what you're saying

I personally have a doffernet view on this

emus: my issue with it the apps section is that imagine an end users is currently looking for providers on providers.xmpp.net, made a decision on what provider to choose and is now in the market for a client. The user will then click on the apps section of that website and have a very bad user experience because it recommends two unmaintained clients

Where [this page] is on xmpp.org and links out, without recommendation, to sites such as jj, snikket, whatever

since ever: central communication in a decentral.network

And lunch time, so I shall seagull out of here.

> Daniel: > 2023-11-10 02:03 (GMT+01:00) > emus: my issue with it the apps section is that imagine an end users is currently looking for providers on providers.xmpp.net, made a decision on what provider to choose and is now in the market for a client. The user will then click on the apps section of that website and have a very bad user experience because it recommends two unmaintained clients Its a not uptodate and we didnt got it right when we moved two to the archive. but noobody gets to any client from threre

> Kev: > 2023-11-10 02:04 (GMT+01:00) > And lunch time, so I shall seagull out of here. Enjoy

What about an explicit disclaimer on xmpp.org, like a banner or something. > The XSF and xmpp.org is meant for developers (and people interested in specs). If you are an end user, ~go away~ check out JJ, Providers, Snikket, ...

emus: so you are saying the user story I outlined is not realistic?

Agree to disagree then 🤷‍♂️

Which story?

sorry

I mean which are you refering to right now, lost track

> imagine an end users is currently looking for providers on providers.xmpp.net, made a decision on what provider to choose and is now in the market for a client. The user will then click on the apps section of that website and have a very bad user experience

If the goal is to not let end users lose time and patience on xmpp.org (which seems reasonable to me), I think it has to be explicitly stated somehow. "universal/open standard for messaging", "living standards" [...] are all things that most end-users will have no clue what to do with, and that does not tell them explicitly "this website is not for you, but you may be interested in using XMPP-based services/'apps' anyway".

Daniel: No, they can (and we will fix this) but they purpose since ever is that xmpp clients offer a good choice right away, if jot just automatically give them a good one. No intermediate steps, forget about the website, its a nice to have, but not something we want users actually go to in the end. Like you do in conversations or quicksy, just with more servers. thats the gold standard. We try to server this in a federated manner

Yeah I guess that answers the question of who the website is for then

Daniel: You tend to say developers, but no. The project has users in mind. because thats were it delivers to.

We also see it of course as service to developers in the way to save them time with this question they either refuse to solve or can maintain good enough. Furthermore they can also enhance their service guiding them to the correct support instances for example

Unfortunately, the discussion on this always tend in any direction but not on the situation of the servers, direct advantages to general onboarding or how questionable we as community did maintaining such lists it before... thats really frustrating. Besides the compliance tester which was also announced to be turn off (?) we dont have no general instance of evaluation and quality anymore in the network. IM Obersavtory did also remove any ratings.

we could just have two buttons on xmpp.org developers and users

and then they go to different pages. developers has specifications and implementations/who uses this

and users have jj, sniket

not sure where providers fit there tho. could be either way judging from the responses

also, unpopular opinion, i disagree completely that ibr "without checks" eases onboarding.

> we could just have two buttons on xmpp.org > developers and users If we use the screenshot MattJ provided earlier and link the 'join us on xmpp' to joinjabber.org it would be pretty much that

Specs for devs, a join button for users

And keeps the diff on the website minimal

I tried to avoid the term "users", and also make the text of the buttons actions

In the unlikely case that joinjabber.org turns evil and recommends matrix or signal we just undo the change

Sure

> I tried to avoid the term "users", and also make the text of the buttons actions agreed. lets change them to develop for xmpp and join xmpp :)

and yeah we could put the join xmpp to a page with projects as i said. with sniket and jj being two of them

I like the wording MattJ proposes. I was just saying that from a functionality perspective the proposed change is pretty much exactly the 'developers go here' 'users go there' thing

yeah makes sense

> I like joinjabber.org and I can imagine a future in which xmpp.org just points end users to joinjabber.org for all their end user needs I'm a confused potential new user that ended up on xmpp.org after being told about this XMPP thing and now I'm being linked to this jabber thing? *Closes tab in confusion and goes back to Facebook messenger* 😞 ↺

Is this an ad for https://joinxmpp.moparisthe.best/?

Haha almost forgot about that, yea I should put updating it in a cronjob and it could live at join.xmpp.net :)

"Daniel> In the unlikely case that joinjabber.org turns evil and recommends matrix or signal we just undo the change" That'd be fun with such a domain name :D

> MSavoritias fae.ve: > 2023-11-10 02:32 (GMT+01:00) > we could just have two buttons on xmpp.org > developers and users like that approach too. Id rather also say people that are interested to build solution, which dont per se need to be developer only

tbh i could see an argument also that xmpp.org doesnt need to have any development docs

aside from xeps that is

we already have modernxmpp

and xsf may not be the right place to actually write down dev docs. because its not where xmpp is used

but its acentral instance and I still argue this is where we should improve

Central communication, right? :)

heh. i think i sit with MattJ here. xsf doesn't need to be everything.

> MattJ: > 2023-11-10 03:31 (GMT+01:00) > Central communication, right? :) 100 points for Matt - yes 😌

So let's have a central place for users, i.e. joinjabber.org, and xmpp.org is the central place for developers

> MSavoritias fae.ve: > 2023-11-10 03:32 (GMT+01:00) > heh. i think i sit with MattJ here. xsf doesn't need to be everything. Certainly not, but thats were I see people will reach out first

If users come to xmpp.org, we point them to the right place

it would be interesting to change the focus of xmpp.org to be developers

Im not convinced in more fragmentation over websites personally, but that does not seem to be the majority opinion

fwiw I'm only a single voice at JJ but I don't want it to be the place for "all users". For example fascists can go @#$% themselves, and I won't be sorry. And while this is an easy example, the limit doesn't actually stop here. So even though it'd be great that more users benefit from the (server) policies we try to encourage / community we're trying to build, I doubt it pleases everyone and I'm sure over time there will be more communities like us

> Im not convinced in more fragmentation over websites personally, but that does not seem to be the majority opinion while i do think more websites and initiatives are not bad, I do think that we need more communication between said sites. both to not duplicate work without a good reason and to interconnect this sites. ie. right now people cant find jj, providers, modernxmpp and xmpp org easily from each other. which we could do

like our own webring :D

pep.: I think that's fine. If/when joinjabber.org develops into a direction we don't like we can just stop linking to it

...the 90s called.

pretty much yeah

Yes! I remember I had a "links" section on my website or skyblog or whatever a long time ago, and that was actually nice :)

yep. and then we dont redirect people to search engines. (which most of them are garbage and people wont find anything anyway)

> pep.: > 2023-11-10 03:41 (GMT+01:00) > fwiw I'm only a single voice at JJ but I don't want it to be the place for "all users". For example fascists can go @#$% themselves, and I won't be sorry. And while this is an easy example, the limit doesn't actually stop here. So even though it'd be great that more users benefit from the (server) policies we try to encourage / community we're trying to build, I doubt it pleases everyone and I'm sure over time there will be more communities like us And that is hopefully fine and great to, but I personally have my issues with strong political opinion in this context and espeically people starting to blame and exclude each other being facists, assholes or whatever if it is the case, or worse, if not. Maybe let me make this suggestion. We separate the two purposes: Developer (I still prefer another term) and Use of XMPP. we keep the getting started site, but on the top we have big banner linking to that joinjabber project. So people can go and we will see what we do with the rest.

we can also link modernxmpp in a better way, but I think its more for developers

"I personally have my issues with strong political opinion" so you have strong political opinions over strong political opinions? :D

:-) maybe I'm going more deeper into this now. but such expression tell me its not only about xmpp anymore, thats difficult to me

Who exactly operates joinjabber? The website stays super vague and just mentions an "international collective of individuals"

its whoever shows up at the project room we have

there are some regulars

meson, because that's what it is. We have decided a set of values for joinjabber, and you can come and participate if you want

and some people with access to the server

> we can also link modernxmpp in a better way, but I think its more for developers agreed. its for devs

emus, of course it's about XMPP, and at the same time, of course it isn't :P

pep.: And that is in general very fine

yeah joinjabber exists regardless of xmpp. to put it more clearly: people have ideas about communities/chats and xmpp is the best solution for that right now to make these ideas.

And that is fine too

We do have xmpp.org/software, which lists clients, which is what "user" are looking for. It's not the same or the same focus as JJ, but it's something

Right after some hilarious mail admin stupidity involving redirecting board emails to me instead of to mailman (all restored now), I'm logged into the Twitter account. So we do have access to Twitter, not just through Tweetdeck that we used before.

And again I'm glad to have a mail system-fluent Edwin on hand for the things I invariably don't know how to do.

*XMPP Community* Reminder to consider to join the upcoming XMPP Vision & Strategic Workshop We intend to discuss our organization and future of the technology we use, develop and thrive across the XMPP Community. Date: Tue, 14th November 2023 Time: 6:00 - 9:00 pm UTC Online & in English Questions: https://xmpp.org/chat?xsf Everyone welcome - spread the word! https://fosstodon.org/@xmpp/111387292602565749

Kev: thanks both of you

Kev: is that a temporary offer?

Have I managed to miss every previous mention of that Workshop? Has it gone through my email without me seeing?

dwd: emus emails get stuck in Gmails spam filter

what 😅

dwd: I once sent it to members@ and spammed the community

everyone is invited

Daniel, Good point. I keep discovering fragments of threads in my spam.

> what 😅 I don't understand why actually. I blame Google 🤷‍♂️

😞😞 I how many people havent received the really important mails :-/

mailbox is actually a nice provider

> mailbox is actually a nice provider Indeed

Can Thunderbird have something to do with it?

I don't know. I don't think it's your fault

Google gonna be Google, don't think too much into it

whats the state of PRECIS now?

If you are an XSF member maybe please check you spam folder for my mails - unless you want them to be there :-)

i tried to support this, but seems neither ejabberd nor prosody support it even after some years, so can we declare it officially dead?

isnt the state that there is no migration path still?

Google are exceptionally fussy, but emus's emails fail because both DKIM and DMARC report a FAIL, so this is reasonable behaviour. The emails seem to be DKIM signed, but the signature covers the reply-to header which our mailman changes, so I wonder if it's that?

I just learned the next version of Nextcloud Talk will add federation. They considered using existing protocols for that, but Matrix was to complex with all its weird syncing and XMPP was not HTTP based. Given there were already discussions to add HTTP APIs for XMPP c2s, maybe we should also consider that for s2s.

😭️

> dwd: > 2023-11-10 07:14 (GMT+01:00) > Google are exceptionally fussy, but emus's emails fail because both DKIM and DMARC report a FAIL, so this is reasonable behaviour. The emails seem to be DKIM signed, but the signature covers the reply-to header which our mailman changes, so I wonder if it's that? oh that topic again

I think MattJ talked about a websocket binding for S2S. Certainly most of the simpler cloud hosting options for simple containers (GAE, ElasticBeanstalk, etc) don't allow arbitrary TCP traffic, but can allow websockets.

> larma: > 2023-11-10 07:14 (GMT+01:00) > I just learned the next version of Nextcloud Talk will add federation. They considered using existing protocols for that, but Matrix was to complex with all its weird syncing and XMPP was not HTTP based. Given there were already discussions to add HTTP APIs for XMPP c2s, maybe we should also consider that for s2s. Can do anything about it?

Lol I told Frank to use XMPP like 6 years ago or so

And offered to help develop some s2s bosh

But he wasn't interested

dwd: IIRC the nextcloud limitation is that the don't want long running processes

I think moparisthebest already has a websockets s2s version or something in his proxy

The technical aspects aren't hard; it needs specification and discovery though.

Is someone about to invent BOSH for s2s?

Unless the requirements have changed (they might have since my last discussion with them was 6 years ago) I think this is pretty much what it would take

Would it make sense to reach out and join the discussion?

Yes, a "pure" REST-a-like interface for XMPP S2S would be quite challenging.

That would basically be activitypub

emus: As they have their stuff now implemented, I doubt there will be any motivation to change things now on their end (as it also wouldn't add any value for them to use something like s2s bosh if they're the only ones to do so) but I think it might be worth considering for the future for other interested parties.

singpolyma: yes, something like activitypub (both for c2s and s2s) is probably not far away of what some people would want to have.

> larma: > 2023-11-10 07:46 (GMT+01:00) > emus: As they have their stuff now implemented, I doubt there will be any motivation to change things now on their end (as it also wouldn't add any value for them to use something like s2s bosh if they're the only ones to do so) but I think it might be worth considering for the future for other interested parties. can you maybe help to lead discussion on that

The benefit of a hypothetical s2s bosh is that it is probably relatively easy to implement on existing servers at least compared to something entirely REST with its own grammar

The downside is that it doesn't really cover all use cases and if we ask for a server side chane have, we can also invest the time to do the full thing.

The downside is that everyone must support and deploy it for it to be useful

That's true for both BOSH s2s and REST-XMPP s2s.

Realistically we'll just end up making a gateway if we decide it's worth it

It could even run next to a Nextcloud instance (or multiple), I imagine

Adding seamless XMPP support to existing deployments

How will that work?

(because in reality most deployments probably can run a long-running process somewhere, even if Nextcloud don't want to require that)

Someone will complain that it doesn't work for their hosting that only allows HTTPS on port 443 and absolutely nothing else whatsoever

Direct TLS s2s is something that is coming :)

But then you require all servers to do that if they were to use XMPP as their primary s2s protocol

I mean: I'm not talking about some gateway/bridging thing (in fact Nextcloud even advertises using Matterbridge to bridge Nextcloud Talk to XMPP), I'm talking about other systems using XMPP for their own s2s.

You can run the gateway somewhere else then

bidirectional gateway if they have federated addressing and s2s on their side.

mod_s2s_nextcloud

MattJ: the whole purpose of Nextcloud is to bundle things

Prosody and mod_rest?

Things that are short-lived processes written in PHP

I mean, what you propose is certainly possible, but I don't think it would be a solution in this context

Then don't have a gateway, and we'll just remain unable to communicate with Nextcloud Talk users

It's not about us, really. It's about third parties being unable to use the protocol we built.

Due to constraints they choose

Yes.

I'm fine with not trying to solve every single problem in one protocol

Constraints that are being applied to everything because nobody complains when those constraints are enforced by firewalls!

Meanwhile we have everything we need in the protocol to nicely gateway to other things

The constraints are reasonable. And it is possible to do what XMPP does and be compatible with those constraints

have they said why they want to use only http?

I don't know I'm fairly sure I could have pulled of s2s bosh. But they weren't interested 🤷‍♂️

sorry if its a stupid question

> have they said why they want to use only http? I think the short lived process is the bigger constraint than the port

But yes

ah its another port thing

I think Nextcloud is only an example here really. Being able to send/receive a message on my server without spawning a full-blown, long-standing XMPP server isn't that unreasonable IMHO ✏

It's not unreasonable. But it's also relatively straightforward for anyone who actually wants to do it

Start a short lived full-blown XMPP server that shuts down after handling each s2s stanza?

why cant this be done ^

Because how do you handle incoming stuff if your short-lived server isn't running?

> Start a short lived full-blown XMPP server that shuts down after handling each s2s stanza? Imho it's stupid on the nextcloud side of things to want to do this. But protocol wise it's simple

MattJ, by starting one first, via socket activation! :)

ah right

ah so thats what bosh/rest is. a thing that listens to connections and starts the server and then shuts it down again.

Their web server is obviously a long-running process

But that's okay, because it's HTTP

Bring back inetd!

OG socket activation :D

Why do I have the vaguest memory of someone actually having implemented a PHP BOSH thing like this? Probably c2s tho, but still.

Fritzy did.

I think.

> Their web server is obviously a long-running process nginx_mod_xmpp ↺

Honestly 99% of webapps are also a seperate long lived process these days. Even most PHP deployments (via fcgi or similar)

Thank you all for your suggestions for xmpp.org earlier. I went ahead, un-cluttered the menu structure a bit, and adapted the main entry buttons on the index page (plus explanation text). I'm not sold on linking directly to jj from the index page though, since I think we should have a "Getting Started" for developers as well. This would be a page which lists several resources, e.g. Specifications, jdev/xsf chats, standards mailing list, link to libraries/servers section (software), etc. to give developers an easy entry point. There could be a "split" between developers and "users" on that page. That's why I originally opened https://github.com/xsf/xmpp.org/issues/1259

> larma: > 2023-11-10 08:04 (GMT+01:00) > It's not about us, really. It's about third parties being unable to use the protocol we built. > MattJ: > 2023-11-10 08:05 (GMT+01:00) > I'm fine with not trying to solve every single problem in one protocol But is it an "easy" to solve problem and would help to propagate the protocol?

> cal0pteryx: > 2023-11-10 10:59 (GMT+01:00) > Thank you all for your suggestions for xmpp.org earlier. I went ahead, un-cluttered the menu structure a bit, and adapted the main entry buttons on the index page (plus explanation text). > I'm not sold on linking directly to jj from the index page though, since I think we should have a "Getting Started" for developers as well. This would be a page which lists several resources, e.g. Specifications, jdev/xsf chats, standards mailing list, link to libraries/servers section (software), etc. to give developers an easy entry point. There could be a "split" between developers and "users" on that page. That's why I originally opened https://github.com/xsf/xmpp.org/issues/1259 Id also love to see more onboarding and hands-on material

And that also could be an interesting thing on Google Season on Docs.