XSF Discussion - 2014-03-27

somebody needs to write an anti-spam proof-of-work XEP based on dogecoin for next week.

much wow!

Ge0rG: thanks for volunteering :)

in the context of http://arstechnica.com/security/2014/03/apps-with-millions-of-google-play-downloads-covertly-mine-cryptocurrency/ it would make a great prank for yaxim :>

intosi: I never have written an XEP before, but I would try if there is a "writing XEPs for dummies" kind of resource

Ge0rG: Something like {xep 143} perhaps?

Ge0rG: XEP-0143: Guidelines for Authors of XMPP Extension Protocols is Procedural (Active, 2011-07-08) See: http://xmpp.org/extensions/xep-0143.html

Zash: perhaps, yeah.

not sure if I will be able to comply with all these points within the next five days, though

hey Kev, was missing you here

Here now :)

I read back on the room history. Regarding node identifiers, on principle I still believe they should be opaque. I know we have the exception with auto-subscribe / caps. I don't know how that interacts with your ideas.

ralphm: Ah, thanks. Opaque to what, thought?

To the server or the client?

Kev: well, I'm kinda ok if it has some meaning for a particular application

I think that's what I'm implying.

but on the protocol level it should remain opaque

To the server it's just opaque as always.

ok, just making sure

But the applications will construct the nodes in a known way.

*node ids

I still have horrible memories of how ejabberd implemented pubsub with node identifiers that included the owner's JID

And could use the id of the template node to get the id of the publishing node.

Our usage of pubsub nodes at Mediamatic also gave them an application-specific structure. That's fine.

Problems rise when different applications share the same nodeid namespace, where node identifiers have some meaning.

This is also why I think that eventually you don't want generic pubsub services for such applications.

We started out with one for Mediamatic, too, and quickly reimplemented it as a pubsub 'shell' around some business logic

made my life so much easier

Right.

I think your Mediamatic needs were somewhat more advanced than the requirements for this.

This is fairly simple "get a bunch of form templates, let people submit completed forms".

The problem is that there's no way for the pubsub service to indicate whether it's suitable for hosting forms

Say I create an XMPP firewall whose configuration is exposed as pubsub nodes, and the node id represents namespaces to filter

MattJ: At least for my use case, that's fine. Configuring templates is an administrative function.

That's the problem though, it's fine for you... but there's no way for a client to know when it's not fine

and the form-fillers might find stuff they didn't expect when they look at the node

I'm not quite sure I understand the problem.

A form-filler will always be OK, because if the templates have been published, the foms will be published OK. Short of much silliness from admins trying to break things.

In your case, yes

For a template publisher, I'm not sure that's any different to any other pubsub application. You can't just go publishing to a ~random pubsub service and hope you're allowed to do so.

That's fair enough, yes... but what about form-fillers? Are they also configured with which pubsub services are safe to look for forms on?

Because you mentioned automatically picking them up from disco

I'm using the presence of templates to indicate this.

So the node exists with a name in a certain format *and* the item contains an element of a certain kind?

If the node id is in a given format, you can try to request templates from it.

If the template then isn't really a template, I guess you're not going to present it to the user, so not being able to publish it is irrelevant.

Could it be that adium.in has a script auto-checking their server on xmpp.net. EVERY single time I check the wall-of-shame, they are running a test.

maybe the last test just never completed?

I'm not sure I'm comfortable with them using that name...

> Test started 2014-03-27 10:00:03 UTC 22 minutes ago.

I'm going to presume it's nothing to do with Adium?

Nope

That's adium.im

I assumed Simon had just typod :)

there is a test going on for adium.in though

And it has SRV records for XMPP

And is running ejabberd

xynhps: what about hell-banning them with a 59minute long test that always results in an F?

Haha

I'm looking forward to Peter's promised cleanup of https://xmpp.net/directory.php#

imho that list should only be for A-grades.

no yax.im on that list :(

MattJ: where did you get to with the public server directory that you mentioned during the Portland Summit?

Nowhere I'm afraid, and it's going to be a while till I can resume

adium.in test seems to be automated.

https://xmpp.net/result.php?id=25275

That's yesterday, at 10:00 as well.

oh, good idea. I will add all my servers for automated tests as well.

https://xmpp.net/result.php?id=25097

Etc.

xnyhps: what about monetizinig that as a service? auto-test daily for $5/month?

I have a feeling they just want visibility in the list

I wonder about adium.in: if StartTLS is required, why are there pre-TLS SASL methods on the list?

speaking of service monetisation and my question to MattJ, would anyone be interested in an XMPP component that they could fire off a "authenticate this new user with SMS" iq at, user gets SMS and clicks link, you get a real-ish user proof back from the component?

Simon: generally a nifty thing, but not something that I would add to yax.im

Ge0rG: Aside from visibility, what's the point in scheduled retesting anyway? It's not like the test changes daily and people's configuration probably neither.

xnyhps: I have tasked myself with modifying the config once a day, just for the sake of it. Didn't you?

I'm going to presume Ge0rG was being sarcastic.

:)

Ge0rG: ejabberd being silly? (re pre-tls sasl)

Zash: ah, kay

With PLAIN before TLS too

Kev: sorry I tuned out a bit, but I have the same concerns as MattJ. Purely conceptually, I don't like the idea of needing a heuristic based on node identifiers with a certain pattern and coincidently having particular types of items.

Well, it's not a heuristic, it's an algorithm.

I'm abandoning all pragmatism in my argument.

Kev: I disagree about it being an algorithm.

Ignoring implementation details like generic v.s. app-specific pubsub server, I'd want to just use disco to find out of a thing is what I'm looking for.

Which is exactly what happens.

Or what I'm proposing.

We used to have a push side in XEP-0030, but abandoned that in favor of pubsub. Going back to the discussion earlier, I might agree that generic pubsub services would need to be able to accept custom node config fields.

Kev: I'm talking about using disco#info to find that a 'form endpoint' or whatever you want to call it.

(... that a node is ...)

But we don't have this mechanism.

If we had this mechanism, I'd have suggested using it.

What we do have is node identifiers.

So I'm suggesting we use them to identify nodes :)

Kev: as I mentioned, I am arguing conceptually, and would rather have it work as I describe. If you really need / want to do this in some kind of generic services, we should bring back the ability to set identities on nodes, and/or require that generic pubsub services accept custom form fields for node config (and maybe subscription options,too)

Kev: and obviously, doing it as app-specific pubsub service, it is trivial.

I'd quite like if our story as the XSF isn't "XEP-0060 is great, but for even the most trivial real-world requirements, you'll have to hack your service because it's not suitable" :)

What's not clear to me so far is what the problem is with using node identifiers to identify nodes.

IMHO XEP-0060 specs even too much - for example specific roles and their capabilities. Much better to leave 60 as a framework and have application specific enhancements in new XEPs that reference 60's fundamentals.

I accept that it feels as if you should be able to disco#info stuff to find out more about it, but AFAICS the node identifiers are sufficient for this.

Kev: I agree that the story is not great in this respect. On and off, I've been thinking of an example application to build a tutorial around, and haven't really found a 'good' one.

Kev: the problem with it is that node identifiers are specified to be opaque. If another app has a similar setup, with similar URIs as node ids and the same type of items (xep-0004 namespace, right), what to do? That's why I called it a heuristic.

Simon: we all agree that XEP-0060 has to be split up and I have always promoted a more lenient interpretation of the specs.

Another app won't have similar node IDs unless it goes trampling over other people's namespaces.

If we're worried about people trampling over namespaces they shouldn't, the same argument applies to all our protocols.

Simon: the roles and all that are not part of the protocol per se, but of business logic of a generic service, maybe.

Kev: except that node identifiers are not specified to hold URIs. Of course the chance of conflicts is almost zero. I just don't like it conceptually. Same with well-known nodes in disco, one of those necessary evils. You do have precedent there, so it probably works fine in practice.

It would be so much better if 'discovery' isn't spread over multiple places.

ralphm: Conceptual argument aside, do you have a suggestion of how better to specify this in practice?

Kev: in a generic service as they currently exist, no

So the pragmatic thing to do is to continue writing a proposal as I've described it, then?

Kev: yes. I hope I haven't wasted your time.

hi

Thanks. I don't disagree that disco would be nicer conceptually. Just that we've got to work with what we've got :)

and we probably should work on the problems here

either by suggesting the practise as a 'best' one, or fixing the expectations of generic services

I think that there's a lot of improves that can be added to Pubsub

FWIW, I think doing it 'this way' could be picked up as a best practice.

Kev: my point

If you standardise a way of doing pubsub, choose a node prefix, and then append application-specific data to that.

e.g. we might have all geoloc nodes identified by starting with urn:xmpp:geoloc:repository/ or something.

Kev: we could even easily suggest node identifiers in general being URIs. This is backwards compatible in most real-world cases.

Kev: I'm not sure I agree about that

So e.g. if the military wanted to use geoloc, they could use xmpp:geoloc:repository/tanks/goldfish/1 xmpp:geoloc:repository/tanks/goldfish/2 etc.

Kev: are you working on a Pubsub client ?

edhelas: Depends what you mean.

Kev: I think that's a bit restrictive and I'd also would expect app-specific node identifiers

I'm looking for clients which implements correctly pubsub to test the compatibility with my project (Movim)

ralphm: Maybe geoloc was a bad example. Although it's not entirely clear to me that it was.

Kev: also, we lack a mechanism for searching with patterns in disco

edhelas: what does a client supporting pubsub mean?

edhelas: Swiften/Sluift have pubsub support that you can use.

that he can discover, read, write on nodes

But a generic pubsub client doesn't make a great deal of sense.

You can do that with Sluift very easily.

edhelas: that's meaningless in itself

edhelas: clients implement as specific *use* of pubsub

edhelas: http://swift.im/blog/swiften-pubsub/

ok thx

ralphm: Although my requirement is slightly different to the geoloc example I gave, because of the expected format of items *plus* the semantics in having templates plus completed forms published.

Kev: the thing they push forms too, is that app-specific? If not, why doesn't *that* implement pubsub?

^to

No, it's all a pubsub service.

so they don't really use regular form submission, righ

t

'regular form submission'?

normally you request a form (using XEP-0004 protocol), fill in fields and then submit it

Hmm.

Is that true?

XEP-0004 doesn't provide a mechanism of requesting a form, or submitting it, AFAIR.

Only the format of the form itself.

wait huh?

So I'm suggesting that both the empty forms, and the completed forms, are pubsubbed.

oh you're right

it is always part of another protocol

never mind that part

So you have a bunch of nodes that are identifiable by their ID that contain templates (empty xep4 forms).

yes, I understand

I was confused with how pubsub uses forms

So when a client wants to publish a form, it fills in the template, generates the right ID for the publishing node (by s/template/result/ in the node ID or similar), and publishes. All using xep60.

and who gets those forms?

where is the sub part of the story?

Whoever is subscribed to those nodes.

I think I like the general concept here, by the way

There's some sort of incident, a user picks the appropriate form to report it, fills it in and presses 'send'.

right

Then the relevant incident handler operators will receive the notifications in their clients.

And although my requirements are along these lines, it actually works more generally - e.g. you could use this in an application that has users fill out questionnaires, or whatever.

So my intention here is that the 'get templates, fill out, submit' bit is standardised through a description of process, and that then the nodes are specified to have a standard and an application-specific part.

aye

So if you were building a questionnaire application, you might have something like urn:xmpp:pubsub-form-template:isode.com/employeesatisfaction/2014

I'd be happy to give that a thorough run-through, sponsor or co-edit it

I think the spec itself is dead simple, because there's no protocol, only a way of generating the right node IDs.

yeah, it is mostly informational

So yes, I'm trying to write it up, if you'd like to give it a run-through once I've done that it'd be marvellous please.

but examples would help greatly

Yes, I thought about it not being standards-track, but I think it is really.

Yes, examples would help. I'm vaguely inclined to clear the first hurdle of Council before I put too much work into it.

you have my no-objection, for what it is worth

Thanks.

since we are telling people how to use identifiers, it surely is standards track

gotta drive a car

Enjoy. Thanks.

catch you later

I'd like to know if you have a comment to make on the prososal I've made yesterday on this email Tags and Pubsub subscriptions in XEP-0048 (Bookmarks)

Kev, the wordpress should be editable right?

at xmpp.org

AFAIK.

k

http://doomsong.co.uk/extensions/render/pubsubforms.html is the bare minimum to describe what I've been going on about, I think.

Kev, what was the XEP that describes JID binding during chat sessions?

Tobias, 296?

-xep 296

Tobias: XEP-0296: Best Practices for Resource Locking is Informational (Deferred, 2011-08-18) See: http://xmpp.org/extensions/xep-0296.html

mathieui, thanks, i think that is the one

http://wiki.xmpp.org/web/Mojo_Lingo_Application_2014 VS http://wiki.xmpp.org/web/Ben_Langfeld_Application_2014?

Well up until recently companies could be members of the XSF.

Still can, no?

What's the status of the amendment?

The change to not allow companies was uncontentious, I think.

But bylaw votes need to go through a members meeting.

Which is the next summit or ?

It's the next members meeting.

The summit isn't a members meeting.

Members meetings = those things we have four times a year to vote on members stuff.

ah those :)

The XEP1 changes are somewhat more contentious.

is there an XMPP Extensions Editor?

A team, even.

the link from http://xmpp.org/extensions/xep-0143.html#submit leads to a page not mentioning anybody responsible

is there already a candidate for the 2014-04-01 XEP?

Not of which I'm aware.

Kev: are you part of the above-mentioned team?

I am not.

it was decided best for the council and editor team to not overlap

Ge0rG, http://xmpp.org/participate/become-a-member/editor-team/

Lance: I don't think any such thing was decided, actually.

The opinion was presented, but I don't think there was any formal acceptance of it.

Tobias: maybe that page should be linked from xep0143

not officially, but that seemed to be the opinion in the air

Ge0rG, maybe...something for the editor team to fix :P