Add support for externally served attachments

[fancypantalons]

Unfortunately, bitlbee (which is what I'm using as my IRC bridge) doesn't appear to support the imgstore API in libpurple. As a result, I want to steal an idea from irslackd and sms-irc.

In those bridges, attachments are written out to a location that's accessible via web server, and the resulting channel message points to that location.

The idea would be:

1. Introduce three new settings:
   1. "Use external server for attachments"
   2. "Local directory to store attachments"
   3. "URL where attachments are served"
2. Have the default behaviour be the current behaviour (i.e. use the imgstore)
3. If these settings are configured, when an attachment is supplied:
   1. Write the attachment out to the storage directory with an extension suitable for the mimetype.
   2. Generate a URL based on that filename and the base server URL specified.
   3. Dump the generated URL into the conversation.

Let me know if you'd be interested in this (or have other ideas)! Meanwhile, I'll probably start working on an implementation... the lack of attachment support in bitlbee is definitely annoying!

[fancypantalons]

Yeah... I... already did it. LOL.

You can find an initial implementation in 89f3f4526ae2467f165046433d5ee9f70b3eda69. It's basically exactly what I described above and some basic smoke testing seems to demonstrate it's basically working.

The error handling leaves a lot to be desired, here, in that the user doesn't currently get any visible feedback (outside the debug log) if the attachment directory is malformed.

This commit also adds two dependencies: gio-unix-2.0 (for the file operations) and libmagic (for the file type sniffing and extension determination).

[hoehermann]

Thank you for another contribution. As with the group chat, I want to read through your code before I merge it. I have some reservations regarding additional dependencies. I would like to have an (automatic) switch: If the dependencies are not met, compilation should still continue, but features won't be available. From experiences with purple-gowhatsapp I learned that bridge service users (bitlbee and spectrum) are not likely to be satisfied. Sometimes, their wishes outright contradict the normal (Pidgin) user's. I'd see these features as purely optional and untested, if that is okay for you.

Semi-Unrelated: I have been experimenting with a Windows compatible variant of this plug-in at https://github.com/hoehermann/purple-signal. It does not use signald, but contains the signal implementation itself. What do you think of that? Do you see any particular advantages in using signald? I am interested in your user experience. :)

[fancypantalons]

I have some reservations regarding additional dependencies. I would like to have an (automatic) switch: If the dependencies are not met, compilation should still continue, but features won't be available. From experiences with purple-gowhatsapp I learned that bridge service users (bitlbee and spectrum) are not likely to be satisfied. Sometimes, their wishes outright contradict the normal (Pidgin) user's. I'd see these features as purely optional and untested, if that is okay for you.

LOL, yup, absolutely a valid concern. Unfortunately, an automatic switch is probably not an option unless the build is moved over to autoconf which is... a pretty heavy lift. It's been years since I tried to introduce autoconf into a project and I don't recall it going well...

As an alternative, we could add a compile-time option to the Makefile? So you'd run something like:

make ENABLE_EXTERNAL_ATTACHMENTS=1

At least then folks could opt in to the feature and associated dependencies.

[fancypantalons]

Semi-Unrelated: I have been experimenting with a Windows compatible variant of this plug-in at https://github.com/hoehermann/purple-signal. It does not use signald, but contains the signal implementation itself. What do you think of that? Do you see any particular advantages in using signald? I am interested in your user experience. :)

Honestly, the big advantage of signald is to you, the developer, since you don't have to own the responsibility for keeping up with the Signal protocol.

Of course, the flipside is that you are now relying on the signald maintainer (who I have to say is really quite responsive!) to keep his project up to date, which creates risks for you.

For me, personally--and I am not a typical user!--I'm, I think, indifferent? I run libpurple-signald with bitlbee and ZNC on a personal server as an IRC bridge, so an extra dependency on signald doesn't bother me. I could see it being a real nuisance for less technical users, though!

[hoehermann]

compile-time option to the Makefile

I am totally okay with that.

introduce autoconf

A definitive no on that one. I prefer cmake. I already use cmake for purple-signal.

the big advantage of signald

purple-signal uses the signald code, but integrated into the plug-in. Data is exchanged via callbacks instead of JSON via socket. It eliminates the need for an additional, independent service. Some might like this, others might not. That is why your opinion matters to me.

libpurple-signald with bitlbee

I was told there were other signal plug-ins specifically geared towards bitlbee (or was that spectrum?). I assumed they were superior.

[fancypantalons]

compile-time option to the Makefile I am totally okay with that.

Cool! I'll get 'er done!

I was told there were other signal plug-ins specifically geared towards bitlbee (or was that spectrum?). I assumed they were superior.

You might be thinking of spectrum. For Signal, the only option right now is a purple plugin, and yours is the only one (that I've found) that actually seems to work and is maintained!

As for the rest, I mean, it's clear to me that an integrated plugin that doesn't require an external service has some serious advantages, if only because there's fewer moving parts. I'm just not in a position to assess how much harder that is... signald seems to do a lot of heavy lifting, and I have no idea how much of that would need to be replicated.

But if I have a choice between two plugins that both work equally well, where one requires signald and the other doesn't, yeah man, I pick the one that doesn't!

[fancypantalons]

FYI, I've pushed f45dc52a5b8be3b8d5b2754c9a04f12af0b5b1ba. That commit adds the compile-time setting so the feature is optional.

[hoehermann]

Nice work. With a bit of luck I can read and merge both your contributions this weekend. :)

[mooomooo]

If I may chime in, in the case of integrating code into the plugin, I'd consider looking into https://github.com/AsamK/signal-cli -- It seems to support a more up-to-date version of the Signal protocol ( and also communicates via json messages ). This is purely from a feature perspective; I don't know anything about any code internals.

[fancypantalons]

If I may chime in, in the case of integrating code into the plugin, I'd consider looking into https://github.com/AsamK/signal-cli -- It seems to support a more up-to-date version of the Signal protocol ( and also communicates via json messages ). This is purely from a feature perspective; I don't know anything about any code internals.

signald and signal-cli are actually built on the same substrate (libsignal-service-java), it's just that the former isn't yet integrated with the latest version of the library (which is something the signald maintainer is actively working on).

So given the choice between basically rewriting the thing to use signal-cli middleware, or rewriting the thing to directly integrate with libsignal-service-java, the latter would seem like a more direct, obvious choice.

Again, the big question is: Do signal-cli or signald in any way take over some of the complexity of libsignal-service-java that you'd be forced to reimplement by directly incorporating the library. I suspect the answer is "yes", given the bits of the signald code that I've looked at, but...

[hoehermann]

@mooomooo @fancypantalons In https://github.com/hoehermann/purple-signal, I actually use https://github.com/AsamK/signal-cli. I boldly chose to do so for having signal-cli as an example I could build upon. But yes, interfacing https://github.com/Turasa/libsignal-service-java directly would probably be better. I usually like the abstraction for ease-of-use, but in this case, removing one dependency makes fewer moving targets to hit. :)

[hoehermann]

Merged.