jdev - 2024-11-21

Hello everyone, can anyone help me with the problem? I want to create a python bot that will log in under my account and receive new messages sent to me. These messages are then sent to the telegram bot and I can view them on my phone. But here's the problem, after I pass xmpp to the authorization request, the error "Failed to connect" appears (the library I use is slixmpp). Maybe I'm not sending all the data to the server? p.s. If I check the connection with the server via cmd, the packets are successfully transmitted

pechka: any more details? Need to know why it failed to connect

you are descriping a Gateway to telegram which I do recommend trying Slidge

Here is the information from the console after launching the application: PS C:\Users\pechka\Pyth> & "C:/Program Files/Python313/python.exe" c:/Users/pechka/Pyth/bot2.py Using slower stringprep, consider compiling the faster cython/libidn one. DEBUG:asyncio:Using selector: SelectSelector DEBUG:slixmpp.plugins.base:Loaded Plugin: RFC 6120: Stream Feature: STARTTLS DEBUG:slixmpp.plugins.base:Loaded Plugin: RFC 6120: Stream Feature: Resource Binding DEBUG:slixmpp.plugins.base:Loaded Plugin: RFC 3920: Stream Feature: Start Session DEBUG:slixmpp.plugins.base:Loaded Plugin: RFC 6121: Stream Feature: Roster Versioning DEBUG:slixmpp.plugins.base:Loaded Plugin: RFC 6121: Stream Feature: Subscription Pre-Approval DEBUG:slixmpp.plugins.base:Loaded Plugin: RFC 6120: Stream Feature: SASL DEBUG:slixmpp.xmlstream.xmlstream:Event triggered: connecting ERROR:__main__:Failed to connect to server DEBUG:slixmpp.xmlstream.resolver:DNS: Querying SRV records for yax.im

I can also provide the bot code

That particular error message seems to have been removed in 2010, so maybe try updating slixmpp? At least specify which version you use?

https://slidge.im/core/

I'll try to implement data transfer through this

How bad of an idea is it to implement deferred XEPs? Some of them have really cool ideas I want in a client but are deferred, like XEP-0113: Simple Whiteboarding or XEP-0196: User Gaming

It Depends

I do also want to have XEP-0071: XHTML-IM but most likely won't due to compatibility concerns

> How bad of an idea is it to implement deferred XEPs? Some of them have really cool ideas I want in a client but are deferred, like XEP-0113: Simple Whiteboarding or XEP-0196: User Gaming I assume the two here wouldn't cause many problems as they won't really be conflicting with anything ↺

Deferred are usually in that state for lack of interest or becasue the authors are busy with other things. Just do it, implement what you think makes sense and then post to the authors or mailing list about your experience.

Will do then, may take a while to get everything running with this project, currently still planning everything out with the guy I'm working with

In principle, none of the XEPs should conflict with anything else. Other clients might not understand them is all.

> I do also want to have XEP-0071: XHTML-IM but most likely won't due to compatibility concerns zayd: like what, many clients implement it ↺

> zayd: like what, many clients implement it Oh, I thought most had removed it ↺

zayd: any reason why you want to use XHTML-IM? I find XEP-0394 a lot more elegant, and some dev teams are actively working on it.

> zayd: any reason why you want to use XHTML-IM? I find XEP-0394 a lot more elegant, and some dev teams are actively working on it. From what I've seen, XHTML-IM has a lot more you can do with it. Haven't looked into 0394 though. ↺

XHTML-IM is a restricted subset of XHTML. XEP-0394 is extensible, and can already do most of what XHTML-IM can do.

i'll take a look when i can

zayd: out of curiosity, which client are you working on?

'394 also doesn't look as tempting to simply stuff into .innerHTML and open up all the exploits vectors

I'm not part of any existing project, I want to start a new client with Qt+QXMPP and am still planning things out right now

OK

0394 is a lot less capable and a lot more weird

In their efforts to deliberately NIH, both 393 and 394 end up a bit weird, to my eye

393's efforts to use markdown, but make sure it's subtly incompatible so you can't use a markdown library but have to write your own, I find particularly noteworthy for oddness.

While I'm not a fan of 394, I think it does largely solve the problem it's trying to solve in a non-insane way.

Wasn't 393 rather based on conventions in chat and email etc?

Maybe I misremember, but I recall Sam going to lengths to make sure that no-one could use a markdown lib for it, in case they got usable HTML out of the lib.

393 mostly matches traditional stuff humans type. Except for the code block syntax

> Maybe I misremember, but I recall Sam going to lengths to make sure that no-one could use a markdown lib for it, in case they got usable HTML out of the lib. Ironically some implementations have done that anyway even though it doesn't work right ↺

I'm honestly tempted to do so for Swift, because it's just the sensible thing to do, to my mind :)

Meanwhile if we do 394, we'll probably do it by ... converting to markdown and feeding it into a markdown lib :)

Yeah. I won't do 394 but if I ever do it'll be by converting to xhtml

393 is roughly what email and IRC and XMPP and everything else have been rendering since the dawn of time, it's not for markup, it's just a sensible way to display plain text written by humans

394 is major NIH and worse in every way to HTML, plz stop

There is a way it's not worse than HTML.

i should probably do some xep reading soon

Which is that it doesn't require a double-body.

And that is a big thing.

moparisthebest, but 394 fixes the SECURITY ISSUE!!!!111eleven that you can put different text in markup and plain text versions!

Kev: at the cost of... No one can agree how to count characters? Has that even been fixed yet? Bad trade-off

There's a whole XEP about how we agreed to count characters

426

zayd: well, rich content is probably the biggest flamewar ever regarding XMPP specifications. Every now and then there is a never ending discussion where at the end everybody agree to disagree. If you want more fun, you can add XEP-0481 too.

Just render the text into a picture and send as a http upload (or stateless filetransfer?! (or jingle?!?? (or SIMS°¹#¡)))

XMPP embedded postscript

> Just render the text into a picture and send as a http upload That's what users end up doing anyway. Sending each other screenshots "this is what it looks like to me", "did you receive this"

> zayd: well, rich content is probably the biggest flamewar ever regarding XMPP specifications. Every now and then there is a never ending discussion where at the end everybody agree to disagree. If you want more fun, you can add XEP-0481 too. I haven't read much of the spec, how many rich content extensions are there? ↺

XHTML-IM (officially deprecated but still in use), Styling (XEP-0393) active and popular, Markup (XEP-0394), and content-type (XEP-0481) not used at all as far as I know.

Styling (XEP-0393) and Markup (XEP-0394) can be used at the same time: the first one is just a convention on how to render things we often use naturally (e.g. *strong*), the later indicate how to render the content with position (e.g.: render text from char 6 to 10 in bold).

reasons people are not happy with XEP-0071 (XHTML-IM) is that it has security implication if people just use the XHTML without sanity checks, reasons people are not happy with XEP-0393 is that it's a mixing presentation data and content, and reasons that people are not happy with XEP-0394 as shown above is that it's an original solution. So whatever you choose, somebody won't like it :)

Meanwhile, other popular messaging systems all use HTML embedded in JSON and somehow get away with it without complaints 🤨️

Oh, and XEP-0481 is it's own league: you can put basically anything, and client has to do something with it. However I can imagine it has some use notably with gateway if you can't transmit everything.