From Nicolas Cedilnik to ~nicoco/public-inbox
Thanks a lot for the contribution! It's not far away for merging although I'd like to test it first and I'd like you to confirm that you've also tested it from an XMPP client. I just read the code for now and this is my feedback so far. The bad part: I am a bit concerned about performance. Python is legendarily slow, and usually you want to avoid things like iterating ~char~ codepoint by codepoint this way. Also, python is not very recursion-friendly. I am not sure what would be the right way to go, maybe there is clean parser lib with C extensions or something, but it does not seem that easy to find. Maybe a from-scratch C(ython?) extension would be nicely suited here. The good part: This probably does not matter much since it's for
From Nicolas Cedilnik to ~nicoco/public-inbox
Hello Terenc3, Thanks for your contribution. For some reason, your patch wasn't detected as such by sourcehut, but I managed to retrieve and try it locally anyway. Unfortunately, my tests weren't conclusive. Are you sure it's possible to use bbcodes in steam chat? From my attempts using the steam chat web client, bbcodes are not parsed at all. How do you enable that? Also, in line 279, I think you want to use msg.body.message_no_bbcode instead of msg.body.message
From Nicolas Cedilnik to ~nicoco/public-inbox
So, I think I got something working here: https://git.sr.ht/~nicoco/slidge/commit/a32355000d88 Let me know what you think. -- Nicolas
From Nicolas Cedilnik to ~nicoco/public-inbox
Thanks a lot contrapunctus! -- Nicoco
From Nicolas Cedilnik to ~sircmpwn/sr.ht-discuss
Hi all, Seems that this was never fixed for me. Example from today: https://lists.sr.ht/~nicoco/public-inbox/patches/38085 I realise that I have a .py script along my 4 build yaml file, and that it is also listed as pending on the link above. Could this the be reason why all the triggered builds display: >Error fetching logs for task "None" I would really like to get builds for my inbox patches working someday, any help is appreciated.
From Nicolas Cedilnik to ~nicoco/public-inbox
On 04/12/2022 12:52, Alex wrote: > That is to say, let's say I have two accounts on WhatsApp, one called > "Alex", and the other one called "Super-Secret Alter-Ego" Alex, what did you do‽ This is a public mailing list! > Linking both of these accounts/devices into Slidge Slidge will not let you do that. One slidge account=one bare JID, and there's no way of "legacy multi accounting" with a single JID. I you really want to do that, just create another JID? Gajim, Dino, Conversations [...] all allow XMPP multi accounts in a unified view. > Maybe resources on the legacy user JID will work, but do clients allow > you to choose which resource to send from (or differentiate history > based on the resource)? I don't think so, but clients *could*. Another XMPP account/JID sounds like a reasonable option if you really want to multi legacy account with
From Nicolas Cedilnik to ~sircmpwn/sr.ht-discuss
Hey Moritz and Conrad, Thanks for your replies. An example of stuck patch is https://lists.sr.ht/~nicoco/public-inbox/patches/37285 but if you're saying it's fixed now again that's fine. We'll see on the next submitted patch. I ended up giving rw access to the contributor in question, so we won't need builds-triggered-by-inbox anyway... until (hopefully) a new contributor shows up. ;) Sorry if my little rant came out harder than I meant yesterday. I'm very happy with sourcehut, and grateful for the good work you guys put in. Cheers,
From Nicolas Cedilnik to ~nicoco/public-inbox
Thanks a lot Alex! I cannot emphasize enough how much I am happy that you are contributing to slidge. > it's unclear what happens when multiple linked devices share a > contact; how do we choose which account to send from? Supposedly, contacts are bound to a unique session instance, and thus are never shared between different sessions. They are discriminated by the stanzas "from" attribute and dispatched to the appropriate session (see `BaseGateway.__register_handlers()`). I might be missing something here; have you witnessed some sort of leaking between different sessions? > danger of hitting rate-limits Yes, this is something that should definitely be improved. On other plugins I do a full roster sync/avatar fetch on every startup but this is not great (some libs actually implement caching stuff though). Some persistent store for avatar data is needed…
From Nicolas Cedilnik to ~sircmpwn/sr.ht-discuss
Hi all, Thank you Moritz for your answer. It's been two months and patches-triggered jobs are still not launched unfortunately. I hate to be that guy, but I must say I am quite disappointed by the radio silence from the sourcehut team, both on IRC and here. I still don't know if something is wrong in my setup or if this is a known issue. In the latter case, I would be happy to have an idea if this is going to be resolved at some point or if this is just a wontfix. Rant over. -- Nicoco
From Nicolas Cedilnik to ~nicoco/public-inbox
Thanks Hugo! I am all for disclosing how slidge work and not providing a fake feeling of privacy. However, I don't want to scare potential adopters by making it sound like it's worse than it actually is, especially in the README. I think it is already clear that slidge is a convenient way to route all your comms to XMPP and not a "privacy solution" or anything like it. >Communication between Slidge and the client will not use OMEMO, >so messages are also exposed to the XMPP server. For slidge to work, the XMPP server needs special configuration, so basically you are expected to be the XMPP server admin. I know that you plan to run slidge on a rpi and prosody on a VPS you don't trust, but this is an unusual setup. Maybe this OMEMO part should be in the user