Kevpep.: he's still doing stuff, as he's always been.
ralphmWhat I mean he doesn't frequent this room, which I thought was what pep. was asking.
pep.yeah
Lancehas left
eevvoorhas joined
larmahas left
eevvoorflow why not XMPP for activists? which alternative is there?
ajhas left
eevvoorOf course I would use XMPP if I would like to protect myself.
larmahas joined
eevvoorBy the why, activists already use(d) mail :D. Snowden did, and DeltaChat popped up for activist usecase. ^^
jonas’all the metadata
goffihas joined
jmpmanhas left
Ge0rGIt's too hard to use properly if your life depends on it
pep.That's because "we know". I'm sure others "who know" in other protocols would have other concerns about their solutions :x
Lancehas joined
ralphmIndeed, other protocols have other issues
Allohas left
Allohas joined
eevvooruntil now I cannot see a better protocol than XMPP. Thus I would use it despite my concerns.
eevvoorThere exists no perfect solution until now.
eevvoorAnyhow, you can always use your life if your an activist.
eevvoorAnyhow, you can always loose your life if your an activist.
lskdjfhas left
eevvoorThe enemy comes from all directions. I was always surprised when they appeared.
eevvoor:D
eevvoorhas left
lskdjfhas joined
Danielhas left
Danielhas joined
Mikaelahas joined
ralphmI do think that you'd want full control over your server.
Allohas left
Lancehas left
Allohas joined
pdurbinhas joined
mr.fisterhas left
Visitorhas joined
Lancehas joined
Nekithas left
Visitorhas left
Nekithas joined
pdurbinhas left
Lancehas left
lskdjfhas left
lskdjfhas joined
adityaborikarhas left
adityaborikarhas joined
Lancehas joined
andrey.ghas left
andrey.ghas joined
Tobiashas left
intosihas left
ralphmhas left
Tobiashas joined
Lancehas left
ralphmhas joined
intosihas joined
pdurbinhas joined
Lancehas joined
LNJhas joined
Alexhas joined
Lancehas left
Lancehas joined
Ge0rGhttps://mail.jabber.org/pipermail/standards/2017-August/033123.html is a 401?!
pep.Fun
pdurbinhas left
ralphmintosi, Kev, MattJ?
Chobbeshas joined
Dele (Mobile)has joined
Dele (Mobile)has left
eevvoorhas joined
KevThat'll probably be because of the OS upgrade at a guess.
Lancehas left
KevI believe a strict reading of 612[01] would lead to a server rejecting a stanza of
<message from='...' to='...'><body un-namespaced-attribute="blah>...</body></message>
because of the attribute. I'm currently looking at a patch to M-Link to enforce this. Anyone see issues with enforcing that?
jonas’Kev, I’m not so sure servers restricting the content of stanzas being routed is a good thing
COM8has joined
KevIt is what 6120 says though - that no entity should be sending out syntactically invalid stanzas.
flowKev, a pointer to the relevant parts of the RFCs would be good idea…
ralphmKev: do you mean unknown namespace prefixes, or unknown attributes without one?
KevAnd I suspect you would expect the server to be e.g. bouncing other types of invalid syntax - like message type="nope", for example.
Kevralphm: Unknown attributes without one.
jonas’Kev, content vs. headers
ralphmI don't see how that's a syntax violation.
flowwell message type="nope" is valid IIRC
jonas’that, too
flowalthough I would not recommend it
ZashHuh
Kevflow: no, 6121 enumerates the allowed types.
Kev(And 'nope' isn't one of them
jonas’Kev, and entities which see an unknown type must (or SHOULD?) treat it as normal
Kev(And 'nope' isn't one of them)
jonas’Kev, and entities which see an unknown type must (or SHOULD?) treat it as "normal"
Kevjonas’: No, that's not right.
KevAn entity that chooses not to implement support for all the defined types should treat any of the defined types that it doesn't have explicit support for as the default.
ZashServer rejecting `<message><body foo="bar">blah</body></message>` seems totally fine to me.
KevNot that it should accept ones with an invalid type.
jonas’Kev, right, I misread that
ralphmtype='nope' is *not* invalid for Core?
Kevralphm: 6120 references 6121 for its rules.
ralphmfor IM purposes, yes
flowI always read
If an application receives a message with no 'type' attribute or the
application does not understand the value of the 'type' attribute
provided, it MUST consider the message to be of type "normal" (i.e.,
"normal" is the default).
as "nope" become "normal"
jonas’flow, above the enumeration, there is "type MUST have one of those values"
Kevflow: You should read the stuff a paragraph or so before as well, which explains it further.
ralphm6120 without 6121 is a valid use case. Even XEP-0060 doesn't inherently depend on 6121
jonas’Kev, I’m inclined to say, aside from @to and @from, the server should leave routed stanzas alone.
flowWell it says something about "if included" the type MUST be one of the following ;)
jonas’flow, yes
jonas’so it’s either one of the defined ones, or absent. absent defaults to normal.
Kevralphm: That's a good point, thanks.
ralphmhowever, 6120 does have a schema with a restricted list of values
flowI think the RFC could be better writen/more clear about that, but I am happy to hear that there appears to be a common ground that "type" sould not carry custom values
jonas’(non-normative schema?)
jonas’flow, MUST NOT ;)
Kevjonas’: Incidentally (I'd previously missed this) it's OPTIONAL whether a server does the validation.
ralphmBut type on stanza aside, the earlier example is about unknown attributes on the body element. I think that's totally valid. If servers would block that, it might be a problem for forward compatibility.
flowKev, I still miss the part in the RFC which forbids additional custom unqualified attributes in <body/>
Kevralphm: What about the other cases, like an iq that has three payloads? I had previously believed that a server should be not allowing those through, but as of about 3 minutes ago I no longer think that.
flow(FWIW, I would be happy if such a part exists)
COM8has left
Kevflow: "There are no attributes defined for the <body/> element, with the exception of the 'xml:lang' attribute." is the text in question. I think reading that to say that there are no further attributes allowed in the default namespace would be reasonable. But I was sufficiently unsure as to bring it up here :)
ralphmI don't know, think that 8.2.3 ad 5 is pretty convincingly a MUST.
ralphmand to me 'not defined' does definitely not mean 'not allowed'
ralphmOtherwise the whole idea of ignore what you don't know about, goes out the window.
ralphmAnd rejecting unknown stanza type values is arguably of a different order than unknown attributes.
KevWell, we've always assumed that 'what you don't know about' will be namespaced.
Lancehas joined
KevBut this is all getting a lot muddier than I'd thought it would when I added a ticket for validating syntax.
ralphmKev: I haven't and there are many specs where new attributes, all not namespaced, were added.
jonas’which?
ralphmpubsub is one
KevI couldn't immediately think of any when I was trying earlier, but thought someone else might be able to, thus asking heer.
KevWhat does pubsub add?
ralphmI mean new attributes compared to earlier versions of the spec
ralphme.g. the publisher attribute
KevAh. That's somewhat different.
ralphmwhy?
KevThey're not adding attributes to RFC-defined elements.
ralphmSo what if we at some point have a cis and add an attribute to body?
ralphmWe'd have a mess of older servers that just won't route?
Danielhas left
KevI think the argument against blocking the attributes is strong.
ralphmI missed the argument?
KevYou just made one aspect of it :)
Danielhas joined
KevBut we'd also have to not to anything in cis that was illegal in bis, unless we negotiated cis.
KevBecause validation is allowed under bis.
ralphmSo where is the part that says you can't have other attributes?
KevThere isn't one. There is one that say they're not defined, and another that says you're allowed to validate.
ralphmThe text you quoted doesn't convince me and is not in Core.
KevSo it's a little wooly.
KevIt's not, but it's referenced from core saying "the rules for this are in -im", or somesuch.
KevI'm sold on not blocking the attributes, though.
ralphmwooly indeed
ralphmI was kinda curious about the threat model, though.
larmahas left
larmahas joined
KevSo, different question.
Nekithas left
KevGiven than 6120 clearly says that servers are allowed to validate syntax, what /would/ be fair game for validation.
KevIt seems to be saying you're allowed to validate explicitly against the 6120 schema.
ralphmWell, at the very least defined attributes and their values, and indeed things like number of child elements in iq
madhur.garghas left
jcbrandhas left
jonas’Kev, @to, @from (including stringprep!), @type on all stanzas, presence of @id on IQs(?), number of children in IQs, structure of the <error/> child if present
ralphmI think the schema in 6120 is reasonable to check against
jcbrandhas joined
Dele (Mobile)has joined
KevOh, this gets messy. If I'm reading it right, the schema is more restrictive than the text, but is normative.
madhur.garghas joined
ralphmhow is the schema more restrictive?
KevAh, no, this is stream errors, not stanza errors, ignore.
jonas’if the schema is normative: absence of any unspecified jabber:client/jabber:server namespaced children
jonas’that would show those folks who think they can just drop their XML in there
KevAh, interesting, so message types are defined in the 6120 schema. Making them restricted even for non-IM.
ralphmjonas’: I think the schema language had no way to express this
jonas’ralphm, I’m pretty sure that anything which isn’t allowed explicitly in the schema is forbidden?
KevIncluding undefined attributes? :)
ralphmjonas’: why?
Dele (Mobile)has left
jonas’that’s how XML schema works?
ralphmKev: on the type values and schema, I mentioned that earlier
Nekithas joined
KevSorry Ralph, I can't quite parse what you're saying there. Are you saying you /do/ think that the schema in 6120 restricts undefined attributes on defined elements, and therefore e.g. rejecting ...<body blah='eee'>... is 'ok'?
ralphmNo. I think that checking what's in the schema is fair game, but I don't think we should disallow what's not mentioned
ralphmIs that more clear?
KevThat's clear, ta. But isn't that not how schemas work?
KevUnless the schema defines an extension point (which it does all over the place for namespaced child elements), you're not allowed to extend it.
ralphmHence not normative, IMO
KevIt's explicitly normative for 6120, though.
ralphmHmm
KevBecause it says that you're allowed to validate against it and reject what doesn't match.
ralphmThen I was wrong.
adityaborikarhas left
ralphmAnd I'm unsure if you can add even namespaced attributes to body
KevIndeed, I think you can't.
adityaborikarhas joined
KevWhich I was /not/ expecting.
KevThere's also a question of what 6120 says you can do, and what is sensible to do.
ralphmRight. But on the other hand a much simpler processing model
ralphmPersonally, I'd hate seeing new attributes of any kind on elements defined in these schemas
KevI also think the schema is more restrictive than the text, on allowable stanza errors. IIRC (haven't double checked, but read it earlier) you're allowed your own stanza error elements, but in the schema you have to choose one of the 6120 defined ones.
ralphmBut up till now thought it might be ok
KevAt least if I'm reading the schema correctly (not my speciality
Kev).
Kev).
Nekithas left
ralphmOoh, that needs an erratum
Nekithas joined
KevI also haven't checked the errata. Maybe I should.
ralphmApplication specific conditions should definitely be allowed.
KevYeah. But a server is allowed to drop stanzas that contain them :D
ralphmI'm not sure if <sequence/> disallows other namespaced elements
Danielhas left
Chobbeshas left
Chobbeshas joined
Marandahas joined
Danielhas joined
Dele (Mobile)has joined
jmpmanhas joined
ralphmBut I think we should have this explicit.
Marandahttps://www.arcgames.com/en/forums/startrekonline/#/discussion/1250600/xmpp-sunset 😭 wiki to rectify soon
ralphmIt doesn't say they don't use XMPP going forward, does it?
adityaborikarhas left
adityaborikarhas joined
ralphmJust that they have issues with their c2s causing spam etc.
MarandaThey're dropping
MarandaSupport on sept. 19th
ralphmYeah I read it
jcbrandhas left
ralphmI agree just running XMPP internally isn't so interesting
Ge0rGSpam is killing xmpp everywhere. Sigh..
ralphmLot of negative, insightful, responses
Nekithas left
jcbrandhas joined
Nekithas joined
ralphm“This is a feature that enhances many peoples' gameplay, a feature that larger fleets and chat channels are absolutely dependent on, and terminating it demonstrates that Cryptic is shockingly out of touch with the way the players who spend money on their game play it.
Don't remove XMPP. Take it out of beta and monetize it instead. Charge $10 or $25 for access if you have to.”
Ge0rG> So that excuse doesn't make sense.
Indeed, that looks like an excuse.
adityaborikarhas left
ralphmBy the way it is for all arcgames properties
MarandaYes
ralphmGe0rG: if Google can use that excuse, anyone can
Ge0rGralphm: it didn't make sense back when Google used it.
ralphmMy point
adityaborikarhas joined
MarandaThey chat system platform is shared across all games originally from Cryptic afair
MarandaTheir chat system platform is shared across all games originally from Cryptic afair
MarandaYes
Maranda> Don't remove XMPP. Take it out of beta and monetize it instead. Charge $10 or $25 for access if you have to.”
It's a beta that lasts from 10 years
SeveNot tested enough? :D
SeveThat's sad though :(
MarandaPerfect World never expanded or finalised it when they took Cryptic Studios assets
MarandaSeve: indeed
Danielhas left
adityaborikarhas left
adityaborikarhas joined
Danielhas joined
pdurbinhas joined
Chobbeshas left
pdurbinhas left
ajhas joined
jmpmanhas left
Danielhas left
Dele (Mobile)has left
Danielhas joined
Dele (Mobile)has joined
curenhas joined
COM8has joined
j.rhas joined
COM8has left
Chobbeshas joined
Lancehas left
Chobbeshas left
Chobbeshas joined
Chobbeshas left
davidhas left
jonas’Alex, memberbot does not reply to me
Ge0rGjonas’: can you ping it?
jonas’oh dear
Chobbeshas joined
jonas’now it does
jonas’it also appears to have restarted
Ge0rGjonas’: it will restart your "session" if you send presence unavailable or somesuch
sezuanhas left
archas left
archas joined
jonas’voted \o/
andyhas left
Lancehas joined
lovetoxhas joined
Alex👍
jonas’now that bitbucket is sunsetting mercurial, do we need to take action for anything related to xmppoke? or is that fully migrated to github?
Mikaelahas left
adityaborikarhas left
adityaborikarhas joined
Mikaelahas joined
COM8has joined
COM8has left
Lancehas left
COM8has joined
jmpmanhas joined
COM8has left
Chobbeshas left
Chobbeshas joined
COM8has joined
COM8has left
COM8has joined
andyhas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
Mikaelahas left
Mikaelahas joined
COM8has left
pdurbinhas joined
Steve Killehas left
COM8has joined
Steve Killehas joined
Chobbeshas left
COM8has left
lskdjfhas left
lskdjfhas joined
pdurbinhas left
archas left
archas joined
COM8has joined
COM8has left
COM8has joined
jmpmanhas left
COM8has left
Wojtekhas joined
COM8has joined
COM8has left
Wojtekhas left
patrickhas joined
adityaborikarhas left
adityaborikarhas joined
Nekithas left
Lancehas joined
Yagizahas left
Allohas left
Allohas joined
debaclehas joined
jubalhhas left
jubalhhas joined
adityaborikarhas left
Dele (Mobile)has left
jcbrandhas left
Wojtekhas joined
ajhas left
Wojtekhas left
Dele (Mobile)has joined
Guusjonas’: I think that is all here now, but I'd love for someone with access to the deployment to verify that. https://github.com/xmpp-observatory
pdurbinhas joined
Chobbeshas joined
jcbrandhas joined
j.rhas left
Lancehas left
pdurbinhas left
j.rhas joined
Allohas left
Allohas joined
debaclehas left
Nekithas joined
marc_has joined
mimi89999has left
mimi89999has joined
neshtaxmpphas left
neshtaxmpphas joined
mimi89999has left
mimi89999has joined
Ge0rGmail.jabber.org is still Forbidden.
ralphmKev said there's been an upgrade, and I think nobody's actually looked into it yet
Ge0rGSo did anything happen on the send-presence vs. fetch-MAM vs. receive-offline-messages vs. delete-all-offline-messages front?
XSF Discussion - 2019-08-20