Can't compile due to conflicting copies of curve25519-dalek

[ioistired]

auxin-build-log.txt

running cargo tree confirms the source of these errors

➤ cargo tree -i curve25519-dalek
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
warning: Patch `curve25519-dalek v3.2.1 (https://github.com/signalapp/curve25519-dalek.git?branch=lizard2#829f52e7)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
error: There are multiple `curve25519-dalek` packages in your project, and the specification `curve25519-dalek` is ambiguous.
Please re-run this command with one of the following specifications:
  registry+https://github.com/rust-lang/crates.io-index#curve25519-dalek@4.1.3
  git+https://github.com/signalapp/curve25519-dalek?tag=signal-curve25519-4.1.3#4.1.3

[rugk]

For everyone reading this: Note this issue is apparently a mission critical one for a Telegram sticker bot, see https://github.com/signalstickers/Adhesive?tab=readme-ov-file

It was quite popular and is archived now since "Aug 31, 2024".

https://github.com/signalstickers/Adhesive/issues/32 as I see you are the maintainer, thanks a lot for creating this issue!

I hope you can maybe bring some other people into the boat that may help to bring it up again and fix the technical issues? Do you maybe know some? Like maybe pinging people who contributed before or so?

I am sure there are many people who would like to use the bot (including myself) and miss it very much!

[rugk]

Also maybe could you explain the status/progress on https://github.com/signalstickers/Adhesive/issues/32? So am I right to assume, Adhesive was/is rewritten in Rust? And this failed due to this issue here?

https://github.com/signalstickers/Adhesive is Python code currently only, where may I find the new Rust code?

Concrete questions I'd have are:

• What has been done? How has progress been?
• What still needs to be done? Are there "road blockers"?
• Generally, I see you seem to (need to) use MTProto, is not that Telegram's (e2e) encryption protocol? Why do you need to do so at all? Does the bot really need to accept secret e2e encrypted messages (aka "secret chats"?) or would it be fine not to accept them?
• How much do you estimate the missing workload?
• Also in general, what is this library here – apparently for Signal?. And more important why do you need it? Technically why does the bot need Signal access? Cannot it convert the Telegram stickers with Telegram access only? (Just asking stupid questions?) As a user, I did not see that before, i.e. the Signal stickers were not provided via Signal, but just via a link in Telegram, which I can open in Signal, which was totally fine for me, personally.

These are some things that maybe can also be put into (technical) documentation or so…

[ioistired]

Also maybe could you explain the status/progress on signalstickers/Adhesive#32? So am I right to assume, Adhesive was/is rewritten in Rust? And this failed due to this issue here?

It's planned to be rewritten in Rust, yes.

https://github.com/signalstickers/Adhesive is Python code currently only, where may I find the new Rust code?

There is none as I haven't started on the Rust rewrite.

• Generally, I see you seem to (need to) use MTProto, is not that Telegram's (e2e) encryption protocol? Why do you need to do so at all? Does the bot really need to accept secret e2e encrypted messages (aka "secret chats"?) or would it be fine not to accept them?

MTProto is not just for e2e, it's for all communication with the Telegram servers. But the rewrite is planned to use the "bot API" instead which is an official HTTP API that wraps the mtproto one.

• Also in general, what is this library here – apparently for Signal?. And more important why do you need it? Technically why does the bot need Signal access? Cannot it convert the Telegram stickers with Telegram access only? (Just asking stupid questions?) As a user, I did not see that before, i.e. the Signal stickers were not provided via Signal, but just via a link in Telegram, which I can open in Signal, which was totally fine for me, personally.

I guess I could start work on the bot without a Signal side of it, yeah.