nicoco

About this new asyncio.TaskGroup thing, I found this from Guido on the related GH issue*

> After some conversations with Yury, and encouraged by the SC's approval of PEP-654, I am proposing to add a new class, asyncio.TaskGroup, which introduces structured concurrency similar to nurseries in Trio.

I have never used but have been told that Trio's nurseries make it much easier to handle exceptions in asyncio tasks. Does someone more knowledgeable can tell if this will help? Looking at the docs*, this only seems to be a helper when you want to await several tasks at once, so I am not sure this changes much for exception handling.

* https://github.com/python/cpython/issues/90908

** https://docs.python.org/3.11/library/asyncio-task.html#task-...

Nice! Passing it on a small project I work on I learnt 2 things already: `Path.read_text()` and `with suppress(SomeException): ...`.

You're completely missing the point of my comment. You say "crypto is not as bad as facebook" which is a textbook whataboutism. "crypto" isn't as bad as the Shoah, so what?

I think that's called whataboutism.

I think I remember reading a Cobain interview where he stated this sentence was something he often said when he was invited by friends for dinner or the like. I can't seem to find the reference so I may have dreamt it.

I've long enjoyed bridging instant messaging accounts through my XMPP server, ie, logging in to various service from a cheap server in a datacenter, so I'm with you 100%. I'd like to opt of suspicious login for a LOT of services. It's not like anything critical rely on my skype/facebook/otherCrappyOnlineServiceIStillUseSometimes account anyway...

> Apparently no torrents for this, too bad

I guess someone has not heard about our lord and savior, https://prowlarr.com/ It aggregates search results from various torrent search engine. You choose which search engines you want. The list is impressive and it supports private trackers too.

You're right, --user seems the default behaviour, I did not realize that. Maybe because it's different in Fedora that I also use? Or maybe I was just plain wrong :)

Anyway, I think this does not change the fact that it's a bad idea to populate your ~/.local/lib with python libs, since it may break some python programs installed via apt for your user, or was that wrong too?

On my debian stable, if I want this behaviour I actually have to add `--user`.

But that's not the recommended way to install pypi packages you want to use, with debian at least. This may install dependencies that will break (for your user) some debian packages depending on other versions of said dependencies. The easy way to go is `pipx install west`.

EDIT: --user is not necessary anymore. I think this does not alter the validity of the rest of my comment.

Came here looking for this reference. A comparison table with existing similar projects would be nice.

Movim is great! I don't even use its microblogging features, but the chat part implements emoji message reactions* which are a very convenient way to acknowledge a message, and a way that everybody understands. It may look gadget-y and I suspect a lot of old school hackers might hate them, but I think that we should reckon that they are seen as a standard chat feature by non-techies. I used to be in the hate camp ("I don't want no 'facebook like' in my chats!") but after being forced to use MS teams at $EMPLOYER, I must admit I miss the feature in my (other than movim) XMPP clients.

* https://xmpp.org/extensions/xep-0444.html

Thanks for the information! I added this to my tracker then. Not sure I'll work on it soon, but at least the relevant links you gave me are stored somewhere easy to find now.

https://todo.sr.ht/~nicoco/slidge/46

Thanks for the kind words. So, you use Conversations for SMSes too? The SIM card in your phone is just a mobile internet thing, you don't actually use it to make calls? I'm curious about your usage. :)

Nope, didn't know about it. At first glance, it looks like the pypi package is for sending messages only. Since it's all open source, I guess it should not be too much work to get a slidge-zulip plugin working.

Feel free to open a ticket about it in slidge's todo.

https://todo.sr.ht/~nicoco/slidge

https://slidge.readthedocs.io/en/latest/dev/tutorial.html

I did not know that, I gotta edit a bunch of replies now, thanks for correcting me.

To be fair, one of the reason I use XMPP and not matrix is that I didn't hear about matrix until after I managed to set up my own server and get some of my entourage to use it too, about 5 years ago or so. Interoperability is the important part anyway, and I'll work on slidge-matrix when I fix/improve some stuff in the existing core/plugins.

This seems to still be actively developed and has a quite a lot of people still using it. I think there is some value from XMPP over IRC, but hey, whatever worked for you is cool. What do you use now?

https://xkcd.com/1782/

Arguably, calling other human beings "non valuable connections" does not make the world a better place either.

> I mean it's not that these days you couldn't install a second app if you already have 50 useless i.e. "coupon" apps installed anyway.

Don't get me started on this. It saddens me to see so much resistance from a lot of my friends that don't even want to try a tiny, privacy-friendly, open-source, non-battery consuming app when they have like 50 attention-stealing spyware apps installed on their phone. Marketing works scandalously well.

For signal, telegram and mattermost, I am not too worried since their protocols are documented. Matrix support is planned and should not be too much of a problem either.

About the full-proprietary platforms like messenger and discord that are actively against alternative client implementations, it's probably going to be hard to keep this working by myself. I chose to rely on 3rd party libs for this very reason. But even if these slidge plugins break, I'm still happy to use my XMPP clients for the more or less opened networks.

>Someone who won’t install a trivial and safe free app to maintain connection with you is perhaps not as valuable a connection as one might think.

That's a pretty radical stance and I respect it.

However, I consider that keeping in touch with people that don't get why they shouldn't use Meta or Google is actually more productive than bubbling myself in a hacktivist bubble. I actually have more chance to get them interested in mass surveillance concerns by keeping in touch than by ghosting them.

Slidge can be used to bridge XMPP and signal, and I'm actually more motivated to keep it working with relatively open services like signal than with services from Big Ad.

I personally think XMPP is superior to signal, being decentralised and with an open governance. For instance, I've not yet seen some cryptocurrency crap being pushed at me on the XMPP side, which I very much enjoy. I wish everybody moved to XMPP, but apparently it's not going to happen anytime soon, so in the meantime, I'll try to contribute to making XMPP the best instant messaging network. When everyone moves to XMPP, then slidge will have no reason to exist anymore, and my evil plan will have succeeded.

Probably someday? https://todo.sr.ht/~nicoco/slidge/1

It's actually closer to spectrum2 in how it behaves. I hope slidge will get as rock-solid as biboumi is!

https://spectrum.im/

Facebook does not like alternative clients, but this workaround [1] worked for me. Signal is OK, and Telegram actually encourages writing alternative clients [2]. I'm happy to assist setting it up, come say hi on our MUC.

[1] https://slidge.readthedocs.io/en/latest/user/low_profile.htm...

[2] https://tdlib.github.io/td/

[3] xmpp:slidge@conference.nicoco.fr?join

And I'm really happy there is one client I can use these features with.

It's unrelated, except for the fact that I used the reverse engineering of the facebook messenger protocol by the mautrix team [1]. XMPP has had bridges more or less from the start. [3]

I may add a "matrix plugin" [2] if I feel like it someday, but probably after I implement group chat support. Then you'll be able to use XMPP<->Matrix<->some-other-thing for extra over-engineering points. ;)

I prefer XMPP because it's lighter on resources, server-wise at least, and it's managed through a democratic process, which has it upsides and downsides. As someone I like said "democracy is boring, dictatorship works faster".

[1] https://github.com/mautrix/facebook

[2] https://todo.sr.ht/~nicoco/slidge/27

[3] https://xmpp.org/extensions/xep-0100.html

(author here) This was posted yesterday already [1], but seeing it twice here is an honour (especially since I am not the one posting it).

Let me know if I can answer some questions you might have.

[1] https://news.ycombinator.com/item?id=32713750

"self-bot" is a weird name for alternative clients in the first place. Preventing spam is obviously their justification for being so strict about it.

I believe screen readers are OK, but a Firefox add-on using API calls would be considered against their ToS.

Author here, thanks for your comment, "cool" is what I aim at.

>without anyone on those services knowing I’m using an XMPP client

Slidge acts in a way that (should) make it impossible for your contacts to know you are not using the official app. However, since some services are OK with alternative clients, Slidge does not necessarily tries to hide its "identity". For services that are less tolerant about it, I wrote a quick documentation page with advice about how to avoid triggering their "security" alerts (mostly because they'll see connecting from a data center, unless you host at home): https://slidge.readthedocs.io/en/latest/user/low_profile.htm...

Group messaging is definitely the next big feature I want in Slidge. There were part of Slidge's first iteration, but I decided to postpone them since it was too ambitious for a start. I really want direct messages to work well, and the code to be maintainable enough before I (re)implement groups. You can help by setting up slidge on your server and bug reporting. ;)

Someone mentioned this directive on slidge's MUC* yesterday, but I haven't looked into it too much yet. I guess slidge's plugins should be easier to maintain once this is directive is in application. I should focus on improving slidge's core more then.

* xmpp:slidge@conference.nicoco.fr?join