Last active 2 days ago
View more

Recent activity

Re: [PATCH slidge v2] Implement basic support for WhatsApp 2 days ago

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

Re: Builds triggered by inbox patches stuck in 'pending' state 3 days ago

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.


Re: [PATCH slidge v2] Implement basic support for WhatsApp 4 days ago

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…

Re: Builds triggered by inbox patches stuck in 'pending' state 5 days ago

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

Re: [PATCH] Add a few mentions on communication and encryption 25 days ago

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

Re: Builds triggered by inbox patches stuck in 'pending' state 2 months ago

From Nicolas Cedilnik to ~sircmpwn/sr.ht-discuss

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

— Nicoco

Re: [PATCH] Normalize JID representation in Roster references. 2 months ago

From Nicolas Cedilnik to ~nicoco/public-inbox

Thanks a lot!

I’ll merge this ASAP.
For future patches, try to include [PATCH slidge] instead of [PATCH],
so that CI jobs are triggered with your changes. It seems broken ATM,
but hopefully it will be fixed at some point…


— Nicoco

Builds triggered by inbox patches stuck in 'pending' state 2 months ago

From Nicolas Cedilnik to ~sircmpwn/sr.ht-discuss

Hi all,

I have received patches in my inbox, but the triggered build jobs
are stuck in the PENDING state.

Trying to inspect the details yields 'Error fetching logs for task None’.

Is this a bug or something I have overlooked in the docs?

An example patch with this behavior:

Thanks a lot,

Re: [PATCH] Signal: fix missing profile.name handling 4 months ago

From Nicolas Cedilnik to ~nicoco/public-inbox

>using "no name" as a fallback
I think it would be better to just leave the name attribute to None in this case.
Most XMPP clients should display the user part of the JID in the absence of a name
field in the roster, which would be the phone number in the case of signal.
What do you think?

— Nicoco