Of course, that does leave the size issue. Most people only use a small subset of emojis anyway; I’d be happy to download them as needed and subsequently store them locally, or download a small standard set and optionally download the rest. But then, I also think plain-text :) works. So I may not be the best person to ask.
Sorry for the stupid question, but does Deltatouch depend on anything other than the Rust crate deltachat-rust-core and some Debian packages?
I tried OpenMoji some months ago, and couldn’t get it working. I might be missing something here as noto-emojis are present on the system, but somehow not accessed by the app on Debian. On Ubuntu Touch, emojis work without them being shipped with the app itself.
Apart from dc-core-rust and some Debian packages, DeltaTouch depends on libquirc for QR code scanning. You could remove it, scan QR codes with some other application, copy the code to the clipboard and get it from there in DeltaTouch.
deltachat-time: time related stuff used by Deltachat-core, at this time mainly a changeable system time struct that is used in testing, so you can just change time in the test and the test does not need to wait actual real time.
ratelimit: implementation of a rate-limit algorithm
deltachat_ffi: c-bindings, libdeltachat
deltachat-jsonrpc: jsonrpc implementation library
deltachat-rpc-server: jsonrpc over stdio binary
deltachat-repl: simple client for testing delta-chat without building a full ui, terminal app in “read–eval–print loop”-style, like what happens when you just type “python” or “node” in your terminal and press enter, those two are also REPL
deltachat-contact-tools: “Contact-related tools, like parsing vcards and sanitizing name and address. Meant for internal use in the deltachat crate.”
Was not that hard to find out what they are, most have a description in their Cargo.toml file.
using only deps already in Debian
not sure, I guess this could be true for the UI libraries, but at least delta-chat-core is not part of official debian packages yet.
Kdeltachat: It does not yet have all the features of some of the other clients
It lacks some fundamental features and there is no active development as far as I know, so I wouldn’t recommend it unless for people willing to contribute to it.
Deltachat-cursed (Python)
also no active/recent development at least no new features since some time, could also use contributors.
Deltachat-desktop (Typescript)
I’m working on separating backend (electron specific stuff) from frontend, frontend is only run in sandbox, so might be less of a risk there at least after building and you could in theory also build the frontend with deno and restrict what build scripts can do. electron is not even in debian, so a different backend/browser would be needed anyway, maybe tauri could work better.
we’re also planning to remove like 100+ dependencies from the frontend.
might work if there are available in a format that qt accepts, but looks very different than other emoji packs. But I don’t know if the license is that important, if it is not build in, but just linked as a dependency/font-file?
it depends on the cffi library, deltachat_ffi to be more exact.
Thank you, Simon. I think I stupidly classified anything beginning in “Cargo” as “not documentation” while scanning for information. It was kind of you to actually provide a summary rather than just say “Read the Cargo.toml files”.
I’ve made some initial corrections to my earlier post.
its smaller and simpler, but zbar still rules most benchmarks. Anyways qr libraries are weird and it’s not always easy to really find out what’s the best one in real usage.
This benchmark says: ZXing < Quirc <<< ZBar < SOTA: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8321072/
I think you can not get SOTA, maybe closed source or not public? I can’t remember.
Thanks! The VEGA-funded study’s algorithm has a somewhat lower speed compared to Quirc, and a somewhat higher recognition rate compared to Zbar, in that paper, on their novel test image set. In practice, for Deltachat, I can see that having twice the speed would be better than twice the recognition rate, when you are reading the image off a video of the code, not a still image. The paper is CC-BY, so let’s hope the authors release the code.
It looks as if DeltaTouch is currently the client that is easiest to package in Debian. It has the fewest non-Debian deps, is actively developed, and is already running on Debian. I’m really impressed by the development pace of Deltachat-desktop, which clearly also runs well on Debian and Mobian, but Debian-packaging its much more numerous un-Debian-packaged dependencies would be a lot more work. That said, with the Deltachat core as a Debian package, adding more clients would be as simple as their dependencies make it, and I’d expect multiple clients to make their way into Debian.
Correct me, but I think the dependency-needed tree, omitting the iroh packages and anything already in Debian, would be:
That would be 13 new packages in total. A lot, but fewer than 700-odd. Have I missed any client deps or anything?
(I’ve used the standard “rust-” prefix for Debian packages of Rust crates; it might also make sense for all Debian packages of Deltachat clients to have a common prefix, for discoverability)
I can’t really say much regarding packaging of the core. If a Debian package for deltatouch is within reach, then a switch from quirc to zbar could be considered.
Thanks for your suggestions regarding the emojis. It’s on my todo list, but I’ve got to tackle some other things (Webxdc, vcards, adapt to most recent core) first. Contributions / help with packaging welcome
Thank you for the sanity check. I’ll have to look into this some more, but it looks much better than I thought. I am not an expert in Debian packaging and I know approximately nothing about Rust, so I may be wrong again.
On a complete side note, does anyone know who is funding Iroh development? There’s a company called “n0”, which is registered in Delaware, a US state famous for opaque corporate ownership. If n0 were as transparent about their funding as Merlinux it’d be reassuring.
I am the last person to tell anyone to prioritize emojis!
Organisations that want support to commercially use iroh technology in their products.
They basically want to make an IPFS successor and P2P-connection library that is actually usable in the real world (efficient and fast), read their blog to find out what drives them: Blog - Iroh.
They are friends of the delta chat team, and all the code is open source so nothing to worry about. Also they are always looking for new customers, so if you know someone that has funds to spend on R&D and a usecase, I’m sure they would be happy to talk.
Also you can go to their discord and directly ask questions if you are interested in the technology.
Oh, I can easily see the value, including the commercial value, of Iroh! I did read the blog, and it’s obviously useful. It looks like very solid, competent work, and eminently recommendable. I can’t imagine why the funders aren’t loudly taking credit for funding it.
Everything being open-source removes a lot of concerns, but not all of them. None of the below is specifically about or prompted by Iroh, or intended as any personal criticism of its devs; I’m just discussing general principles.
In the past, funding models have created conflicts of interest, where there are design trade-offs between the funder’s priorities and the users’ priorities. Sometimes the funder’s priorities seem to win out in the finished product (e.g. Google makes money out of identifying internet users, and Google’s WebRTC is not really designed for anonymous use; I don’t think this was malice, just inattention). Transparency is useful for directing effort into projects that don’t have conflicting incentives and thus don’t risk this sort of design compromise.
And sorry to pick on Google again, but they have a history of proprietizing MIT and Apache-licensed code. This is entirely legal, under non-copyleft licenses, but I find it undesirable. It doesn’t happen to most permissively-licensed code, and it rarely happens to code with multiple funders.
So that’s why I like to know who is funding code. I’m not imagine some sort of shadowy cabal maliciously writing malware! And I’m glad to hear the developers have have social ties with the Deltachat devs, I’m sure that’s very technically helpful to both groups.
Sorry for introducing a complete side issue into the thread, I’ll go off and do my homework and get back on topic now.
