jdev - 2021-08-06

hello @all . Can i use XMPP protocol in django with asgi ?

django is python, python is turing complete, yes you can.

Need any library like aioxmpp or only xmpp protocol like ws?

If you're asking for some kind of pre-built integration I don't think there is any, you'd have to build it yourself (probably using a library like aioxmpp)

Are you just wanting to display a client on a webpage though? That doesn't have much to do with django specifically and will be more or less the same for anything

Actually i am looking an alternative of websocket. In websocket a server can accept max 65535 connection simultaneously and its very expensive. My requirement is to implement instant chat app.

amit, huh websockets can only accept 2^16 connections? I somehow doubt this

for each connection it occupy one port number

That's not how websockets work, maybe you're mixing up websockets with regular sockets?

I'm not really sure what you're asking for though, maybe you could explain a bit more about the project and what your needs are and it would help us help you better? This doesn't sound like a django or even XMPP specific question anymore to me, but it's hard to tell.

that's also not how regular sockets work by the way

a TCP connection is defined by (src-addr, src-port, dst-addr, dst-port). in a server, dst-port and dst-addr are typically constant (e.g. 192.0.2.1:443 or 192.0.2.1:5222).

so you only need a single address+port for a server socket and the clients are identified by their address + port

likewise, for a client, you can reuse the same source port as long as you are connecting to different destination ports + addresses

so that "at most 65535 connections because of ports" limit is bogus

for UDP, things are a bit different because it is inherently connectionless, there you might have more constraints depending on the protocol running on top of it. Stuff like QUIC has a connection ID though by which it multiplexes, so there it matters even less.

I always forget that MUC needs PEP for bookmarks and PEP needs disco if you want to receive updates. Guess I have my work cut out for me :(

What are you struggling with?

A mix of motivation to read several giant XEPs that are all needed in some part to make this work, and with disco in particular I just haven't found a nice API that doesn't make it hard to use (eg. I shouldn't have to register a handler with the client *and* a disco feature, I should just be able to have the handler know what features exist and be able to also respond to disco… this isn't hard, I just haven't found a good way to do it in my own codebase)

The disco stuff is all super project specific, unfortunately

I've been fairly happy with the disco API in Verse, not that I've used it much recently

Main thing that tripped me up was the concept of "nodes", which I have to confess I'm still not sure I understand :)

There are two aspects to a disco API, the discovery side and the advertisement side

Indeed; I think I've got all that working fine from the perspective of someone querying for disco info, nodes work, you can walk the tree, etc. (https://pkg.go.dev/mellium.im/xmpp/disco@main), but the advertisement side I've been stuck on for ages for some reason

I haven't seen Verse before I don't think, I'll look up what you do there; thanks

That's mostly just a local registry, right?

per node

Yah, so you end up with a tree-like structure of nodes.

"of nodes" - sure? Disco info/items doesn't actually allow you to discover nodes, right?

You have to know what node you want to query

Disco is not a hierachy of nodes, FWIW.

Right, so you start from the root node (empty node name) and then you can query over all those, etc. to walk the tree

Tree of JIDs, not nodes

It’s a flat pool of nodes. You can construct the node names as you wish so they encode structure within them, but don’t have to, and the structure is by appearance only.

I guess, but since you can't discover all nodes except by querying root, then querying those nodes, it's effectively a tree

At least, it has to be walked like a tree if you want to find all nodes

You can’t query the root to find all nodes for disco.

Right, you can only find the nodes directly under the root node

Ah, there is a 'node' attribute for items

You can’t even do that.

Shown in https://xmpp.org/extensions/xep-0030.html#example-17

I guess after all this time I still don't understand disco then

Or am I thinking of Items and you're thinking of Info? I guess I need to go re-read this for the milionth time

You can have results that include lists of other jids and nodes, so you *can* build a tree, and if you want to build a tree, what you describe is right.

But you don’t have to build a tree, you don’t have to list different nodes under the root, etc.

Oh sure, I mean, I know that you can address any node directly without querying for the top level ones or knowing their name first or whatever

My client (kev@server/res ) could have a ‘kevstuff’ node if it wanted, and that needn’t be listed anywhere.

So the only way you’d know it existed was if you queried it and did or didn’t get a result.

oooh, that's fair too and I hadn't thought of it.

So if your disco responder model relies on tree representation that’s fine and up to you, but it doesn’t cover all the disco uses.

That's a great API consideration that I hadn't worked out, thank you

(still, I find it helpful from the querying entities perspective to provide functionality to walk the nodes like a tree; makes it easy to design browsers like Gajim has, for example, but it's a good point that I shouldn't rely on it)

Personally, I would just register a disco items or info callback or callbacks that gets passed the JID and Node, and then returns a set of results that are concatenated to form a result for the response.

And I wouldn’t in the XMPP Library API do any sort of imposition of structure. Let the application sort it out, only the application knows what it wants.

Yes, having a tree walker in the library for queries is a sometimes useful thing.

We do that for Swift for finding MUCs.

I note that’s walking the JID tree rather than a node tree, mind.

Just having a way to let the application sort it out is fine I guess, but if they've already created a handler for MUC (for example) and passed that into the router that handles XML and pushes it to the right place, it seems like they should be able to say "just use the disco for all the handlers we have registered" and not have to go back and figure them all out

To prevent eg. registering the handler for MUC but then forgetting to register the disco node

err, yes, JID tree for items I guess

Within M-Link we do that, yes. When we register handlers (delegates in our terms), those delegates will be called for append disco results when the router’s queried.

Which is basically > Personally, I would just register a disco items or info callback or callbacks that gets passed the JID and Node, and then returns a set of results that are concatenated to form a result for the response. with the registering being automatic.

yah, it's the automatic part I need to figure out a clean way to do

Really it's an issue with my previous design decisions (I think, kind of making this up as I think outloud). I have a router that you register handlers against to handle certain XML elements. I would expect disco responses to be one of those handlersr. However, the handlers don't have access to the router they're registered on, so how does it know what else has been registered?

Disco has to be a special case.

I think it might, yes. Built into the router or something.

I really hate to do that though; I feel like there's got to be a nice way to make it work without it.

Generally speaking I feel like it it has to be a special case either the underlying spec (nothing I can do) or my API (hopefully I can fix it) has a rather fundamental structural problem. Figuring out which and what to do about it is time consuming and hard though.

I’ve not had a significant problem working disco into any of the codebases I’ve done so, so I don’t *think* the spec is fundamentally broken.

Oh yah, it's almost certainly not

Oh hey, apparently I came up with an elegant (if I do say so myself) way to handle disco, made a branch, and then forgot about it. Glad I looked before starting over on the thing I was talking about earlier.

protip: always check git stash

maybe un-needed if you have a better memory...

Not I…

“14:59:22 Sam> I always forget that MUC needs PEP for bookmarks […]”, for this part, it might be useful to read this, about the current mess that is bookmarks: https://docs.modernxmpp.org/client/groupchat/#bookmarks

:( good docs, thanks. I'll probably just implement the PEP ones. If we detect another client that doesn't advertise support and the server doesn't do the compat thing maybe I'll log a message telling them to change clients or ask their server admin for #compat.

Given the vast majority of clients do Private XML, and the Prosody modules can’t support both PEP versions (and I wouldn’t expect complete synchronisation to be easy to implement in other servers’ PEP modules either, but I’d love to be proven wrong), I don’t recommend implementing old PEP at all any more.

Private XML is the better fallback.

Sorry, I meant just the new PEP one, singular