XSF Discussion - 2018-01-24

https://www.fsf.org/blogs/community/victory-for-libre-networks-activitypub-is-now-a-w3c-recommended-standard

yeah, this means that we will have two standards now, the XMPP-Pubsub one and the Web-ActivityPub one

what a mess, we need another one, unique!

oh wait...

For what? Do they even cover the same things?

personally I was explaining the advantages of building a social-feed standard on Internet protocols and not only Web ones

for several years now

because building on top of HTTP brings maybe lots of advantages (including the "simplicity at first")

but also drawback (overhead, scalability…)

this is only for the protocol layer, functionnality wise there's lots of differences

> The W3C has allowed DRM to move forward on the web All you need to know about W3C

activity pub is pushed by web based networks such as Diaspora or Mastodon which are the most famous ones even if both are youger than XMPP based ones. While I'm sad that they never tried to talk to us or follow what we have done, at least it's standardized and it should be easy to communicate with them.

I shared with you guys that link from the fsf because I felt sad about that. I haven't heard anything about considering XMPP for that standard. And what worries me now is, people involved in ActivityPub, did even know XMPP? I wonder if XMPP didn't make it because people don't know what great things can you have with XMPP.

I know that we have still a lot of work to do in that regard, but for me seems like a loss in our side :/

Not meaning that we have to give up or anything, of course!

> did even know XMPP? I think the problem is NIH, not ignorance

Yeah, could be...

I think you can find easily what we have done after a quick search on any search engine.

SouL: after nearly 10 years, I'm not going to give up, trust me ;)

even if FOSS community is mostly ignoring us

SouL I already talked several times with those guys, also proposed to work with them (and the XSF then)

the thing is that we're not living in the same world, those guy are basically talking about synchronising articles and publications between nodes using HTTP and JSON, because they always done that (they're from the Web)

which is a bit the opposite than us conceptualy wise

let's move XMPP to JSON

there's always the proposal "yeah but we can build a transport/bridge" but we all know how bad it will be

the big difference is that for Pubsub, it's a piece of XMPP, so we are offering way more than just publication synchronisation

basically Diaspora is trying for years to add chat features to the social network, they are actually trying to use XMPP

but because of their architecture it's really difficult

zinid: {xep 295} o/

zinid: JSON Encodings for XMPP (Humorous, Active, 2011-04-01) See: https://xmpp.org/extensions/xep-0295.html

with Movim for example, creating links/features between the social part (Pubsub/Microblog) and the Chat part (MUC…) it's way more easier

and everything is coming from the same stream, use the same protocol

pep., yeah, I know about that one

honestly, I think JSON is doomed as well, just like XML

Everything is doomed

Let's sing the doom song!

even if it can be a mess between all the XEPs and their related features, it's still way more coherent in the end

after webassembly is widely adopted, javascript will start losing position along with json

so people don't learn

we have a great example with stuck XML: xmpp

then we will have examples with json

I❤JSON. `{"secure":true,"secure":false}`

All of IT is doomed. Let's become potato farmers!

Ge0rG: YES!

Oh wait, farming is infested with Bad IT as well... https://motherboard.vice.com/en_us/article/xykkkd/why-american-farmers-are-hacking-their-tractors-with-ukrainian-firmware

potato is not doomed?

even our CPUs are doomed anyway

goffi: it's not the CPUs, it's the assumption that you can share your CPU between code that belongs to you and code that belongs to somebody else.

and by the latter I mean all of the web and cloud and probably some other things.

Will we be competing with the potatoe thing? Zash invents a simple and popular way to grow potatoes, though only a single potatoe at a time? Kev won't show anyone how he does it but try to sell the potatoes to the military? zinid will note how all your potatoe taste like utter crap and will try to grow millions in parallel?

Holger, sounds doomy

That analogy has gone too far.

Ge0rG: And I didn't even start with the client potatoes!

Holger: maybe those are peaches instead?

"peaches"

there is a single "maybe peach", others are "rotten peaches"

Those are called lemons. https://en.wikipedia.org/wiki/The_Market_for_Lemons

Whatever they are, they will only be eaten by other farmers.

Normal people will just stick to French fries.

Has anyone tried to make a potatoe battery powered xmpp client/server?

"xsf@muc.xmpp.org/@Alacer: 403 - modify: Messages from strangers are rejected" @Alacer you might want to fix this

I didn't send any message to you

I also got that

Bork?

Me too!

Me too

It replied my messsages sent here

and at dino's MUC too

http://upload.zinid.ru/muc-errors.png

LOL :)

Hm, things I said... MUC bug?

Zash, no

That's what I'm saying, I got my messages back :)

Zash, the Alacer is not joined the room, but the room doesn't know this and continues to send messages, those are rejected by mod_block_stranges (because outgoing presence is lacking)

Appearing as PMs from @Alacer

Augh what

yes, Alacer has mod_block_strangers enabled on his server

at least this is my theory

zinid, you might want to give a try to poezio's dark theme btw :p

pep., nah thanks, I still need my eyes

mod_block_strangers blocking type=groupchat must've been an awesome idea.

Probably as good as rejecting type=error.

<message from="xsf@muc.xmpp.org/@Alacer" to="georg@yax.im/poezio" type="error" xml:lang="en" id="999020f9-896b-49fb-8a2f-e820b3dab185-3B48E"><inactive xmlns="http://jabber.org/protocol/chatstates" /><delay xmlns="urn:xmpp:delay" stamp="2018-01-24T09:41:26.596476Z" from="jabber.at">Resent</delay><error type="modify" code="403"><policy-violation xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /><text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">Messages from strangers are rejected</text></error><body>Those are called lemons. https://en.wikipedia.org/wiki/The_Market_for_Lemons</body></message>

zinid: you are right, "Messages from strangers are rejected"

yeah, and poezio renders them in a strange way

at least ejabberd is not involved here, so I'm clean :D

this time

ah, Alacer might be using ejabberd with mod_block_strangers

damn

Ge0rG, if we don't block groupchat, spammers can set type='groupchat' to send spam

and maybe some clients will render this

Yes it's not obvious to me that we wouldn't want to block groupchat.

Maybe not return an error for groupchat? But that's not obvious to me either.

Shouldn't Prosody kick them out when receiving an error?

yeah

another weirdness is why Alacer's server didn't send presence-unavailable to the conference

because the server is clearly available and sends stanzas

ah, oh, just noticed it, the server is jabber.at

The errors are returned to full JIDs, not to the bare MUC JID. Should the MUC service kick him nevertheless?

ejabberd didn't kick him either, I got the same error PMs in the Conversations and ejabberd MUCs.

really weird

Holger: no, errors to full-JID are PM errors

Holger: so it's useful to pass them on

Maybe mod_block_strangers should error to the bare JID instead?

So this is all expected.

Hmmm.

Ge0rG, indeed, that's why they are rendered in a separate window of poezio, hehe

Or only return error to bare JID in case of groupchat?

Holger: in case of groupchat, it should track directed presence and not consider those as "strangers"

It does.

Ge0rG, it does, I think there was some connection error or something and presence-unavailable has lost

Right.

Then you need to send errors before processing the presence-unavailable?

what?

It looks like the session collapsed.

ah, you mean in mod_block_strangers

Yes

It took less than a day for this to happen after the jabber.at upgrade. I wonder how much we'll spam people this way. \o/

XMPP, where the corner cases have corner cases.

mod_block_mod_block_stranger_errors

What I need now is mod_block_siwssjabber.

http://web.swissjabber.ch/ - "Apache2 Ubuntu Default Page" That's how a well-maintained XMPP server looks like.

Ge0rG, you're too picky

zinid: I prefer the term discerning :P

sorry, my dictionary is lacking this term

https://news.ycombinator.com/item?id=16222478 3. 2. 1. GO :D

Nice advertisement, but no

> AFAIK XMPP is more geared towards IM than microblogging and it's very complex and difficult to get right due to many extensions.

And webshit is so much simpler, yeah

:D

I really like the idea of an entry-point XEP for the different "profiles" of XMPP

somewhat like the compliance suites

I still need to read through the posts on-list

jonasw: aren't you the new compliance suite author? Make them better! 😀

jonasw, You can apply #557 and close #556 and #555, by the way. I'll get a vote started, at least, on #576 and #559. That's all I see there for Council's action for now, is that right?

https://lwn.net/Articles/741218/ I missed this apparently

https://mail.jabber.org/pipermail/standards/ down ?

Works for me

ah no back now

SamWhited thanks for the fix

ah ah "https://news.ycombinator.com/item?id=16223683" :D

not sure if it's a joke or serious

mathieui, I will read the article, thanks for sharing.

Oh, xmpp agents in the thread

zinid: yes me ;)

goffi: there is yet another one

> and it's definitely not complicated I feel like this is untrue. While I'm all for advocating XMPP, we need to acknowledge that we have a complexity problem and not tell people things like this (which will only make them dislike it even more when they try it and can't figure it out because it actually is complicated) </two-cents>

zinid, me

and jcbrand

Yeah, all criticism is so typical

zinid, I think SamWhited was replying to goffi?

pep.: Not sure who replied to whom 😁

I don't think there's any question that XMPP is complicated. There is a question about whether it's more complicated than it needs to be, although I don't think we're doing too badly on that front, for what we're providing.

So some people claim the Blockchain is a solution to Zooko's Triange. Is that true?

If you list out all the things XMPP does and ask "Is it complicated to write a system that does X?" the answer is 'yes', whether you use XMPP or not.

SamWhited: what do you find complicated ? The basis is just 3 messages, and feature are well separated thanks to namespaces. Of course some features are complicated (Jingle), but it's normal for this kind of feature, and as Kev said, I don't think it's more complicated than needed (I specified for a decentralized network in my comment).

s/3 messages/3 stanza/

Kev: yes, it's to complicated for what it does, mostly due to priorities and resource routing, round trips, inconsistency with mam and stream management (this should be done by a single replication mechanism)

*too

priorities is a legacy feature that should be removed IMHO

and I would appreciate mandatory unique ids on message too, but it's hard to grow a standard like XMPP without this kind of little annoyances

I'd kill for XMPP with GUID message IDs and MAM-Subscription-instead-of-Carbons

can't we redesign everything with with keeping some very basic compatiblity (probably on server-side gateways)?

I'd just define GUID message IDs as mandatory and require all clients to be patched OR ELSE.

But I'm pretty sure there will be some Council opposition.

It's slightly more complicated than that in the face of malicious clients, I suspect.

Kev: I'm sure we can sort out that by restricting the scope to a single user's clients.

That would, sadly, break some of the things I want to do with GUID messages.

Which includes uncontroversial things like message URIs :)

I could arrange with server-generated GUIDs, but then you'd say "but malicious servers"

I think we need to think through these things

Because message URIs (or similar) are a thing we could really do with.

not sure how GUID will help

I'm not asking for much. All I want is to associate MUC reflections to what I sent and to properly merge history resyncs.

I'm thinking about monotonically increasing ids forming version vectors, used for database replication

zinid: but then you can see how many messages I sent!

Ge0rG, true

`SELECT _id FROM chats WHERE jid=? AND from_me=1 AND (message_id=? OR body=?) AND _id >= ?` - this just doesn't cut it.

Especially not if the server is rewriting message bodies.

And it breaks on multi-line messages in IRC transports.

oh yes, IRC transports are very important, we cannot break them

Kev: that wouldn't be a problem if MUC servers wouldn't rewrite message IDs.

Right.

Ge0rG, it should append it though

zinid: what should append what, where?

It. There.

Kev: ITYM "It. It. There."

That's for version 2.

Oh.

hi