XSF Discussion - 2020-06-16

I think it would be nice to have a MUC for new users listet here: https://xmpp.org/community/chat.html

I'm quite new in the XMPP topic, but I also had some problems to get into xmpp. xmpp.org is very technical. jabber.org is not working.

DebXWoody, I think it would be nice to have a MUC for new users first

we don’t have that

jonas’, I know. As I started to work on https://wiki.xmpp.org/web/Guide/de and I think I ask for a mailinglist for users-community, there was a Feedback like "XSF in not responsible for users". This would be fine also, but in such case "we" need to start with something which will take care of users.

yes ✏

I would volunteer for support of German Community.

create an entity which acts as xmpp foss software hoster (gitlab) and discussion platform (discourse) that attracts developers and users likewise?

I thought so too for a while. I am also a fried of "centralized communication" but still having a decentral network

ew discourse

jonas’, it's probably easier for end-user to use discourse than mailing lists

I dont like mailing lists, too.

I like them, but I also like discourse :)

discourse is very non-attractive to me

I think DebXWoody point is a different one

I don't get the point. There's rooms such as xmpp:jabber@conference.jabber.org?join already, and also mailing lists. Nobody uses those. Adding more venues on top will make people use them?

I would've thought normal end users won't use any of those. They'll complain on the app store if something doesn't work, that's it.

For power users actually interested in XMPP (as opposed to just their app), there are rooms already, and they are actually used, no?

Probably because https://search.jabber.network/ can't index jabber.org atm, so people looking for generic discussion channels find whichever ones happen to sound interesting.

> There's rooms such as xmpp:jabber@conference.jabber.org?join cannot be found via s.j.n

Ok. So the fix is migrating jabber.org to Prosody, no?

maybe

depending on what’s going on in there

I wasn’t aware of that room until just now ;)

maybe just removing invalid JIDs from the storage will already solve it?

yes

but that’s apparently hard

because M-Link

> Holger > Ok. So the fix is migrating jabber.org to Prosody, no? The problem with j.o isn't that it's not Prosody, but that it's been abandoned and not had any updates installed in about 4 years. Just for the record ;)

none-the-less, Holger does make a valid point.

jabber.org has the benefit of being very recognizable. If we can improve its utilization, that would be good.

agreed

jonas’: I'm not sure it's hard, is it? Someone just needs to delete the dodgy file off disk (which is pre-M-Link)

I think end-users unable to use their xmpp client are probably also unable to join an xmpp based chat room. and yes the ML is used, but I'd argue mostly not by end-users

Kev, I have no idea

I'm a little offended that people are treating it as M-Link's fault that the jabber.org admins stopped adminning jabber.org.

I don’t have shell there, but that the problem persists for over a year now despite me providing an exact list of invalid JIDs makes me think that it’s hard ✏

Kev: Sorry, I didn't mean it that way at all.

Sounds like it's actually ejabberd's fault 🙂

I also can’t judge if it’s M-Links (the software’s) fault or not. More likely it’s that nobody with M-Link experience is left to work on jabber.org

(If you took over borked data from ejabberd.)

I don't know if it's ejabberd's fault either, it could date back to jabberd for all I know :)

(Actually, it's MUC so it'd be the old MUC component, if of that era)

Whatever, I was just assuming a migration of the service would involve cleaning up the data.

it certainly would

What's the status of the migration?

"In progress"

jonas’: you mean similarly to how the last migration cleaned up invalid data?

Ge0rG, no, because this time people are aware

I was not able to join jabber.org because of Server-to-server connection failed: Connecting failed: dh key too small

that, too, is an issue which is hopefully to be fixed with the migration.

new users should join xmpp:jabber@conference.jabber.org which can not be found on the website of xmpp.org. It's not possible to find via the search website and the most provider are not able to join the server at all. Is is correct?

So maybe add that room to <https://xmpp.org/community/chat.html>? Like <JUser@jabber.org> is listed on <https://xmpp.org/community/mailing-lists.html>?

+1 if the "Connecting failed: dh key too small" is sloved

Though I'm still not sure the "XMPP user" role makes much sense. Users use apps, not protocols. Is there an SMTP/IMAP forum for new Thunderbird users?

> Though I'm still not sure the "XMPP user" role makes much sense. Users use apps, not protocols. Is there an SMTP/IMAP forum for new Thunderbird users? +1

To be fair that's partially our fault because we have been trying to market XMPP to end users

That ^

Which isn't necessarily wrong, depending what you consider 'end users' to be.

we should probably stop that instead improving it

It's the properties of XMPP, rather than particular apps, that are the interesting part to many organisations wanting to use it.

!developers

Daniel, I do think there's room for more than just developers. But we don't need to target everybody for sure

That is - some orgs 'buy' XMPP, and then go to find clients/servers that satisfy their particular requirements.

Kev, I'm not sure that's something I'd target either tbh. XMPP is vast enough so that you'll eventually (very quickly) run into interop issues if you don't all use the same things and have a somewhat tailored server setup

I think it's fine to run such a room, list in on the web site, hang around in that room, and answer the occasional questions. I just don't share any hopes that go beyond that, i.e. building up an XMPP end-user 'community' or something.

I don’t have any hopes for that, I just want to redirect the flow of new users from the technical rooms

Didn't pep. plan to do some joinxmpp website which should serve as a starting point for new users?

yeah there's that, which doesn't get much attention (from me) atm. I was never happy with the name though. I'd say if it becomes a thing it would only represent a subset of XMPP servers/clients (somewhat like snikket, maybe the same, maybe not)

From what I understand this is not MattJ's intention to have Snikket become a thing to which users can openly register, so maybe not just like Snikket :)

Indeed

Yeah, XMPP is very broad and not really a snappy term you would give to 'normal users'. Snikket is better marketing wise but a too small subset of the XMPP ecosystem. ✏

It's not out of the question that a public/semi-public service would use Snikket, but providing such a service is not the goal of Snikket

Every single time I write snippet instead of snikket. 😂

FWIW you can get around the dh key issue by giving ECDHE higher priority, which a soon to be released Prosody version will do by default.

Basically I want to add categories and maybe also subcategories. Also I will add options to show an icon is a variant of another icon (all those about skin color. In UI it supposes to show the original icon in the icon selector but with a capability to select a variant on a long click or any other way). I think to add search keywords in accordance to https://unicode.org/emoji/charts-13.0/emoji-list.html Also somewhat unrelated to emoji but still needed is a way to tell the application where an raster icon may be scaled when presented to the user or it's better to keep the original resolution.

I'm also thinking about metadata features. Like where it's white and black, better looking on the white or black background. Maybe something related to color blindness too.

Recently I registered fedi.chat (like fediverse), thinking that it could potentially becomes a user friendly endpoint.

I also think it makes sense to come up with a new name for the federated network, to keep it separate from XMPP

Jabber is a good name, but trademarked

So I thought maybe fedichat is better

But it's maybe still to technical

It sounds cool at least (to me).

I'm afraid it's gonna be associated with fediverse a bit too much and people are gonna be confused why they can't use one with the other

Isn’t it already an issue with all of these “ActivityPub” software?

You mean MastodonPub?

What is the trademark situation on “fediverse” btw?

> So I thought maybe fedichat is better > But it's maybe still to technical For people not knowing it means federated chat it's just brand/name so still ok. I guess a lot of old people know only WhatsApp is the name of that chat app not knowing it's derived from the english 'What's up?'

So WhatsApp is like Hanuta?

> I'm afraid it's gonna be associated with fediverse a bit too much and people are gonna be confused why they can't use one with the other I guess if you ask random people on the street most won't know about fediverse so that's probably not a big issue.

> So WhatsApp is like Hanuta? No, I can't eat WhatsApp but I can eat a Haselnusstafel. 😂 But yeah, I guess for most elderly it's like that.

pep., I've heard some argue that "fediverse" means all federated things, but yeah, it's mostly associated with Mastodon atm

Zash, I've heard some argue that it's all the federated web things :P

It means whatever you want it to mean!

Fediverse means fediverse! ✏

Between the people who block omemo and those who enable it by default it seems we can't even agree on a common user experience. So I'm honestly not sure if coming up with a name is the most important step here

this ^ (again)

I'm not sure if we need to come up with a common user experience?

Things can happen in parallel ✏

Guus, I think "we" needs to be external to the XSF

I agree

I don't think the XSF should dictate UI/UX

agreed.

Snikket is a good experiment this way. There can be others

There is also modern.xmpp

It's "the same" (person)

Obviously not the xsf. But I think if I installed a fedichat client I'd expect it to work with other fedichat clients

there are more people involved in modern.xmpp

IMO, the UI sprint kinda fell under that initiative

I don't think the UI sprint was meant to be for modernxmpp in particular but it got picked up by modernxmpp (which is not a bad outcome)

Daniel: that's the nice thing about having a name... you can make it a certification. If you want to be able to give yourself the name (or at least be on the official site), then you need to conform to the established rules

i.e. any app that calls itself a fedicaht app needs to adhere to certain UI and UX rules

"pep.> I don't think the XSF should dictate UI/UX" also why I strongly disagree with having 393 as a draft btw :x

jcbrand: I agree that fedichat or what ever could be a certification (or should even) but again it doesn't feel like we as a community will be able to come up with a consensus

I mean omemo is arguably the most touchy subject but that will divide the 'modern xmpp crowd' in half

IMO you just need a sufficiently motivated group of people to start something and then others can either join or not. We don't need buy-in from the entire community

That I generally agree with

I agree that a "common user experience" is not something we're going to achieve, nor necessarily want to

I've been considering breaking Modern XMPP up into "profiles"

Similar to what we've started to do with the complaince suites

We touched on this at the summit, during the discussion about (iirc) "rich status"

For some audiences such a thing would be something like WhatsApp stories, for others it could just mean adding an emoji to your status message

if you end up creating as many profiles as there are products I don’t see the benefits of marketing the profile instead of the product though

Obviously the intention would not be to do that :)

I mean, look at the situation on iOS where we have so many clients that would fall into the "personal messaging" category, but they all have vastly different terminology, UI patterns and feature sets

So, given the existence of both anti-omemo and pro-omemo-only folks, we can't have the most basic interop at all.

I don't think most folks are anti-omemo, just pro-things-that-omemo-prevents.

FWIW.

I'm anti-removal-of-my-choice-in-clients.

fwiw I'd probably still be using poezio or similar, because "I know" and I can adapt to different "profiles"

(and poezio allows me to)

I don't have enough time to write a client per profile

Yay modularity

But I'm not (we're not) your random end-user

what does omemo prevent?

moparisthebest, server side search for one

and don't say history across devices because that just requires some not-yet-existing history sync

moparisthebest, "not encrypting" :P

using non-omemo clients becomes very painful

moparisthebest, until recently, anything that wasn’t part of the body.

Link Mauve, and in practice, still, because implementations are not quite there yet. and the ecosystem has been damaged from that "but we can’t omemo that" attitude for a while now

jonas’, why

moparisthebest, why what?

yes no argument there Link Mauve , but that's fixed *soon*

why if messages are end-to-end encrypted you cannot do full-text search inside the encrypted data on the server?

jonas’, server side search, why

yea but you can on the client

that’s not "server side search"

moparisthebest: Any kinds of references (e.g. emoji-reactions or mentions) (at least until recently) ✏

moparisthebest, yeah, see how well that performs on mobile. conversations is extremely slow because it has to keep the fts index up-to-date

and everyone running prosody or ejabberd on their rpi1 won't be very happy with FTS on the server, meh

Also because people whom it concerns are not saying it or are hiding behind other excuses I will for them (you can thank me later): OMEMO also prevents non-GPL implementations (or at least makes it harder) :) ✏

I suspect the portion of users doing that is *much* smaller than the portion of users running an XMPP IM client on a smartphone.

pep., not anymore it doesn’t

or did I miss something?

to be fair as far as I understand it your situtation jonas’ is a bit special because you turn Conversations on once per week

Daniel, yes, because otherwise it’d drain my battery all the time for the same reason

and Conversations is a bit shitty about the way MAM catchups are stored in sql

jonas’, dunno, just making fun of some who hide behind other excuses while that was actually a pretty obvious end-goal

that can (and probably should) be optimized

and because I can’t stand my phone vibrating when I don’t want to pay attention to it

so far I've heard valid reasons not to use historical omemo, and not much else, that seems right

jonas’, that's what the quiet hours are for

moparisthebest, thanks for just ignoring server-side search and references as a valid reason.

moparisthebest, no, because I want to get non-XMPP text messages (and other stuff) still.

references aren't an issue right?

server-side search, yea, I think that's useless

I guess if you want to offload search to some other more powerful device you can right?

moparisthebest, good argument there, love it /s

moparisthebest, basically anything where the server would want to see the messages, be it for spam reasons, for long-term archiving, etc.

did I misunderstand? I think both Link Mauve and jcbrand brought up good reasons why it wasn't ready to use historically, but that's solved in latest versions

moparisthebest, also the issue of getting a new device and being unable to see previous history.

^ that just needs some history sync thing

"just"

(Which for me would be a deal stopper.)

I've heard WA has history sync, I wonder if they have any documents about how it works

MAM sync between devices should be relatively easy (on paper)

with a bit of luck I might get paid to implement that at some point

Nice

well and with omemo encrypting everything now, also actually safe

jingle; web rtc data channels; and encrypted xml streams (what's the name again)

ok these are less impressive than you would have thought https://faq.whatsapp.com/android/chats/how-to-restore-your-chat-history https://faq.whatsapp.com/iphone/chats/how-to-restore-your-chat-history

so in your home network it doesn’t even hit your server

tl;dr "just back up to $creep-cloud then restore!"

plus is reasonable secure

I'm currently trying to work with a proprietary client that doesn't even display error messages :/ Like if you send to a invalid jid, one that doesn't exist, or in my usecase if the component is down, it doesn't inform the user at all.

Not great :(

Pretty bizarre I would have thought they would at least tell you if it was a invalid jid

"invalid jid" and "jid that doesn't exist" are different things

well it was happy to do test.example.com (a typo on my part)

but yeah that's a fair point.

No indication if you e.g. message xmpp:someone@reject.badxmpp.eu ?

not as far as I can see.

You see all this in the logs so I guess they just haven't implemented it in the gui

https://xmpp.org/extensions/xep-0377.html#payload « I don't understand example 3. Shouldn't there also be an opening for the spam element and an JID in it?

!XSF_Martin, no it's just an empty <spam/>

The text can be confusing yeah. And there's no schema of course

So, I tell the server I receive spam but I won't reveal the spammers JID? Sounds like some academic example that doesn't make much sense. Or am I missing the point about sending a report like this?

Well you tell it with 191 ✏

I also find sad that the two are not separate, but that's a start..

Yeah, but that's only when you combine it with blocking, so it only works with your server, right? I had a look at the XEP because I was curious if you could implement in a client to also report spammers from remote servers to their server.

!XSF_Martin, pep., https://xmpp.org/extensions/xep-0268.html

Fancy CamelCase XML in there

also https://xmpp.org/extensions/xep-0287.html

Is that implemented anywhere?

Yes

Anywhere it matters for us?

Metronome IIRC

The IODEF XEP* could use an example of the minimum you'd actually need, ie JID and a reason ✏

> A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later.

Interesting. How do they implement a spam folder

(0287)

Similar to how you implement the inbox folder? :)

not

Mickaël Rémond is one of the XEP-0268 authors so I would expect it to be supported by ejabberd…

Uh, and MattJ too…

You can contribute to the XEP without implementing it :)

Obviously. 😃

Interessed to see how spam will play out after jabber.org gets a new server.

Pretty much all spam that I receive comes through that.

I wonder how fast updated spam lists will circulate.

You receive spam on your JID there or from spammers using that server?

Wasn't IBR disabled on j.o a decade ago?

Psi Stop Spam plugin is really good :)

Since several years, I do not see spam messages

I receive spam on my j.o account. The senders are on other servers.

Guus: Same!

I've heard there are servers with sophisticated spam filters where the user doesn't need to do anything or solve captchas

Rule #1 of spam fighting: Don't talk about rules of spam fighting

Are you a reflection of myself?

Rule #2 of fight club: Don't assume anyone remembers the plot of fight club

Sam claims that the github permissions thing is confusing. Am I misreading this?

https://share.dreckshal.de/dpm/kEO0ibQ9V3wAql7HMkJMHF2CCk-poH0CzRhToyQrry4.png

below that, it shows a list of all orgs I’m part of

how can I read that except "that software will gain +rw on all things I can see on github"?

I think you read correctly

But maybe you can test for yourself with some oauth thing you build :x

suuure

Yes, Github's lack of sensible roles is horrific.

Isn't the go-to solution to create an account that has access only to the repository it needs to operate on?

Guus, yes, that would be worth a shot I guess

I won’t do that, and I won’t interact wtih that account though

for reasons I’d rather not disclose here

sounds like something that iteam wants to weigh in before we do anything anyway.

indeed

not that I’m not an iteam meamber ;)

it seems like a useful thing to have, also for potential future automation tasks like commenting on issues or stuff

service accounts eh?

they call it "machine accounts" in the ToS and you’re only allowed to have one per human

let's make babies then!

and it’s not quite clear to me if such a usage is a "machine account" or if you need more than just that

flow, that sounds like quite a drastic solution to the problem

woah flow , what a proposal :P

well cloning isn't feasiable yet, so?

I’ll post that to the list, let’s see if Sam and Guus consider that too complicated, too ;)

Guus actually might have first-hand experience on that.

I hear the latter can be annoying

I hear some here actually have a head start on that

Sam's pretty cool though.

But serious: Not that it matters, but I would favor a single git repository hosting solution, preferably gitlab

flow, *personally*, I’d also prefer to just switch over to gitlab, because it’s the easiest solution to the problem (for me, because I know GitLab CI from work and stuff, and what I’ve seen so far from GitHub Actions is not convincing me), but I hear the input from the others that it’ll be pretty disruptive for the community

flow, depending on how "human" is defined, they may only allow one per uniquely identifiable human(?) and thus discard cloning

+1. If the editors think gitlab will help them do their job better we should just do that

^ this (again)

Daniel stop agreeing with me today

I think that someone who edits a XEP should be able to setup a gitlab account

It's not that hard

pep., what about multiple personalities? do they count as uniquely identifiable humans? ✏

yeah I also note that I haven't replied to the list

flow, I'll leave that for you to answer

Daniel, someone off-list mentioned to me that there are concerns about getting a company to allow you to use $platform, and it’s more likely that $company has already allowed GitHub than GitLab

Daniel: It's not so much that they *can't*, as that it's effort, and we need to balance the cost of contributing with the cost of Editor work. And if that means GitLab, so be it - but it's a tradeoff rather than a straight win, I believe.

You are indeed not required

Sending patches to editors is always possible

Plus, as always, you are not required to created a gitlab account to submit protoxeps and patches ✏

I'm happy to do/encourage this (as an editor) if that means we can allow editors to move more easily

*If* it comes down to not burning out our editors VS losing a contribution it'd rather take the former

Because without editors we can't do anything

Daniel: I think that's the point I made on list.

Thanks for the increasing amount of feedback here

I’d really like to get to a point where editors can just hit "Merge when pipeline succeeds" if a change passes all editorial requirements; A simple button function which github doesn’t even have :(

hmm merge trains are not avaialble on gitlab.com, are they? ✏

not for free, methinks

haven’t used them either, are they cool?

well if we'd host our own gitlab we could get a license where they are available

jonas’, I consider merge trains and building merge results a deal breaker

flow, that are two things right away which I’d not like us to have to

(self-host and license)

I’d prefer to buy the respective Tier at the SaaS offering

Uh I probably should have written: I consider *not having* merge trains and building/CIing merge results a deal breaker

(FTR, merge trains are, for both SaaS and self-hosted, on the second tier, i.e. $19/user/month)

works for me, although I believe we could self-host

what do you mean with "building/CIing merge results"?

this one? https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html

jonas’, MRs and PRs are usually build against the branchs HEAD, and not against the merge result of source and destination branch of the MR/PR

jonas’, I think this, yes

read up on it, sounds nice, but I don’t consider this a must-have

not for xeps anyways, because it is very unlikely to have a fast-forward-able merge which breaks things

I wouldn't want to miss it for software projects

I can believe that

but build-wise, XEPs are fairly independent from one another

when merging two different changes on the same XEP, editors typically step in to handle the revision blocks manually anyways

jonas’, I think this mostly means that merge trains are not that interesting for the xeps repo, but not pipelines for merged results

I think what I said also applies for pipelines for merged results

those should always provide in advantage compared to the standard behavior or github PRs and gitlab MRs

aha, yeah, that

I see that one now

assume we had linting to the XEPs repo, and you add a new lint check to master ✏

bbl

still I see it only as nice-to-have

I mean we don’t have that on GitHub and we survived thus far

The XSF got along before Github even

also true

"XSF, P.O. Box 1641, Denver, CO 80201 USA" Is there still anybody at the other end of this box? (reading the IPR)

"Version 1.4 (2008-01-23): Updated legal notices to use modified MIT License rather than Creative Commons Attribution License for the purpose of enabling wider distribution of XEP text and examples, including incorporation into free software; added Disclaimer of Warranty and Limitation of Liability." Does someody know the origin of this change?

Can you mail XEP patches there? :)

Like some challenge?

I just "grepped" for "IPR" in all 2007's subjects on standards and found nothing. There seem to only be stpeter's email in January 2008 saying "it's done!"

pep., IPR sounds more like a board matter

Well yeah but somebody would have raised the issue somewhere else before

And then board taking action

not if board figured out themselves that CC + FLOSS licenses don’t mix well

CC + FLOSS does mix :x and is probably more appropriate to stuff that isn't "software"

Just as MIT says

pep., well, I recall that CC + FLOSS license mixing was not well understood in the 00s

and people were cautious

btw how does versioning of the IPR work? There doesn't seem to be anything in the document saying "and you also accept any change of this document". Does that mean everybody needs to resign? Or that some XEPs are served under a CC and some under a MIT-like license?

(and "you also accept any change to this document" is not legal in some legislations anyway.. like France aiui)

pep., AFAIK, all XEPs use the same IPR template

Yeah but you can't just change the terms of what people agree to if you don't say anything about it :x

indeed

That's why the policy is handing over IPR to the XSF, rather than licensing to the XSF.

(Or as close to it as a local jurisdiction allows)

I see. let me digest that.. ✏

The contribution agreement isn't to license XEPs to the XSF, it's to give them.

hmm ok so CLA-like

jonas’, ^ so I doubt it's possible to do what we thought

(And yes it's actually handled as a CLA on github, but it's a bit confusing)

I obviously don’t know what happened back then, but I suppose if we had to do it again, it’d be a mixture of getting people to re-sign + fixing the rendering so that the difference is clear

Well as I understand it now, resign wouldn't be necessary because you agreed to give ownership to the XSF (that can then change licenses over your work at will). In legislations where this is even possible

(which is probably not in France, still, but..)

Thanks Kev, that helps.

Still curious why the last revision if anybody's got info

yeah, I hadn’t read that yet

I think in Germany, you can do that; contracts with employers typically have something similar

hmm that's a good point. I don't know to what extent one can bend french law to make this a reality though

labor law*. I think it's also possible but I don't know if submitting a XEP would fall under labor law :P

hello cant get confirmation for jabber id