Comments (11)
So, this is an excellent question and I'd love to move forward with this. The main problem is that libsignal-client itself doesn't require store traits to be Send
- this is because it accepts a ctx
raw pointer that's used in different platforms (e.g. a pointer to a database context or transaction context). I wish I'd had more time to experiment on the matter, I'll try to see if I can resume my efforts in the next few weeks.
from libsignal-service-rs.
I think you'd be interested in this: signalapp/libsignal#298
We don't design those traits in this crate. There's more discussion on this example patch: signalapp/libsignal#297.
from libsignal-service-rs.
Ok thank you for this.
I don't think it will be implemented soon and I'm not good enough to create my own fork ... so let's wait 🤷
from libsignal-service-rs.
I'll notify @gferon, he's probably more interested in it than I am (I'm running everything on a LocalSet anyway).
from libsignal-service-rs.
Do you know if there is anything to do about this issue in libsignal? I don't feel like I have the shoulders to modify the code from signal, but I think it would be great to have a send manager...
Is there is a reason why nobody seems to be bothered by this issue, neither people using presage nor people using libsignal... Am I missing something? :)
from libsignal-service-rs.
Hey @EcoloSweet thanks for pinging me back. I must admit I haven't looked at this issue in a while, but I also feel like it's not really a big issue since all apps using this stack of libraries end-up using a single-threaded async runtime without any particular problem (@rubdos is this maybe a problem in whisperfish
and I just don't know about it?).
I also don't really expect a huge benefit from being able to run presage
or libsignal-service-rs
in a multi-threaded async runtime, except avoiding the bad surprise when you get started and can't compile your basic demo. 😄
Obviously, I might be wrong and I'd love to know if you have some ideas why this can be worth the effort.
from libsignal-service-rs.
Thank you for replying so fast! 😄
I feel the same as you about the benefit that a multi-threaded implementation could bring to Signal. This would be almost useless.
However, in my current use of this crate, I have a program doing some heavy computing, program which is async and use multiple threads. When it needs to ping me, it is done through signal.
I would like my code to be like SignalPing::send_message(...)
(with SignalPing struct containing manager) but since manager isn't send, i need to spawn a local task, with signal stuff living in a separate task and use channels to communicate with this task.
It works but it isn't very elegant.
However, I can see that there is a lot of effort to put in refactoring the code in multiple crates. I imagine this problem isn't that bad and doesn't worth spending hours on changing everything...
from libsignal-service-rs.
However, I can see that there is a lot of effort to put in refactoring the code in multiple crates. I imagine this problem isn't that bad and doesn't worth spending hours on changing everything...
It's not only crates, it's also Android and iOS and NodeJS code. That's the most annoying part: making sure those all behave.
It's not like we don't want it to be Send
. I've been looking at having Signal process the decryption in a separate thread, too. For Whisperfish specifically, I'm relying on Tokio's current_thread
scheduler I/O behaviour for qmeta_async
to work. So as long as I don't refactor that into the multi thread scheduler (and I don't know how, currently!), a Send
implementation will even be useless for me :'-)
from libsignal-service-rs.
I don't see how this does not bother you, there must be something wrong in my implementation...
Since manager isn't send, it must be in a task from a localset. But if you are in an environment where you don't manage the runtime (for example in a library), how come you to be sure of the task executing in a localset?
I have to spawn a new thread, where I start a new runtime, where I create a local set task where I put my signal future. This doesn't seem right 🤣
from libsignal-service-rs.
I actually do manage my own runtime, there's quite a thing going on in qmeta_async
for that, including a manually managed LocalSet
(for completely different reasons than what you state here). My whole application runs on a current_thread
scheduler. The Presage examples also all run on a current_thread
scheduler.
That said, I don't think you need to manage your own LocalSet? Can't you start a task that constructs your Signal client actor and spawns it with spawn_local
?
from libsignal-service-rs.
Just to give a little example were we stumbled upon this: crayfish
Background
Crayfish is a backend for Axolotl that was started to replace the old textsecure backend step by step with an libsignal-rs based approach. As the existing frontend and backends are web and go based, we chose to use a web socket to interface to crayfish.
Issue
We use warp
to serve the local web socket and listen for requests. warp
require a Send
future as request handler.
Solution
We decoupled the web socket from the request processing via another server style mpsc
tokio channel with oneshot
callbacks (code). Alternatively, we could just replace warp
with something single-threaded.
from libsignal-service-rs.
Related Issues (20)
- Send message HTTP status 428 not handled
- Remove e164 / phone number from ServiceAddress
- Refactor/merge ServiceCipher::open_envelope and ServiceCipher::decrypt
- Support contact discovery HOT 2
- Add support for ACI/PNI HOT 2
- PlaintextContent not handled HOT 2
- serde_json fails parsing empty HTTP 200 response HOT 1
- Groups v2 getAuthorizationForToday stopped working HOT 2
- Not sending SyncMessage if only linked device HOT 4
- Rework the pre-key management
- Upgrade to libsignal v0.31 or later
- Trigger PreKey-fetching on SessionNotFound
- Add ability to set user-agent HOT 1
- Can't send messages
- Receiving messages failed due to: `SignalProtocolError(InvalidKyberPreKeyId)`
- `TryFrom<EnvelopeEntity> for Envelope` contains strange (and outdated?) logic
- Attachments are encrypted with synchronous code in the executor HOT 1
- JSON Invalid Padding
- MessageSender::send_contact_details seems to have some parameters too many
- Groups Fail with Newly Linked Devices
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libsignal-service-rs.