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

So, I think I got something working here:

https://git.sr.ht/~nicoco/slidge/commit/a32355000d88

Let me know what you think.

-- Nicolas

Thanks a lot contrapunctus!

-- Nicoco

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.

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

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,

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…

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

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

Shall a make this an todo entry in builds.sr.ht tracker?

— Nicoco