I don’t remember exactly but I think I recall there was talk at one point to consider LibSodium as it can compile to WASM. However the SJSC lib has the advantage of being small-(ish) and convenient to be included as core within the HTML. I think that lib sodium was a bit too heavy to be part of the base size of TW.
One of the issues is that any crypto code must be separate from tiddlers or plugins as it is needed for bootstraping the TW system (in the same way the core code is).
Sure a different crypto lib could be used to replace the SJSC lib though doing so I think might be an exercise for someone willing to fork their own modified version as SJSC is just so convenient for the official TW code base.
The advantage of the built in crypto library is, that it is completely self contained, with no external dependencies.
Your suggested library seems to have 8 external dependencies: https://git.duniter.org/libs/g1lib.js/-/blob/main/package.json#L41. Several of them have other dependencies.
Only 1 package has some info about 3rd party auditing. I don’t see, why a crypto library needs node-fetch as a dependency, which in turn have plenty more dependencies … node-fetch is for networking and imo has nothing to offer for a crypto library.
If it is “compiled” and minified, how big is it the whole stuff?
Integrating PGP-like functionality in TW is an interesting idea, but it does raise some difficult questions. In particular, if TW is the means for performing the crypto operations and for reporting the results it is very hard to ensure that an adversary had not interfered with the wiki (perhaps reporting the results of the data integrity checks wrongly). In its usual forms, TiddlyWiki is inherently hackable – there’s nothing to stop somebody from opening the HTML file in an editor and making any modifications they like. So, any integrity assurance emitted by TiddlyWiki would not be trustworthy.
One solution to the conundrum is for the crypto operations to be performed by an external tool that can be independently verified on its own, such as the PGP suite.
First, I’m a big fan of IPFS, and convinced its unique properties enables some interesting new use cases for communities on the web. Bunker BOX looks like great work in that regard.
I may well be misunderstanding the scope of your question. I tend to look at questions from the perspective of the core and the desire for universality. I understood the discussion to be about signing content within a TW so that it can be cryptographically verified.
What I meant about being inherently hackable is that there are a large class of theoretical threat models where a TiddlyWiki can be taken over by an adversary. For example, social engineering might be used to induce somebody to install an innocent looking plugin that has nefarious hidden functionality. For most of us, in everyday life, the risks are negligible. But tools that verify integrity must have a high standard of proof. It’s not my area, but I think that there are philosophical limits here: one cannot trust what an untrusted entity asserts. A trusted entity is needed to start a chain of trust.
I imagine that in your application the chain of trust might well be rooted in the guarantees that IPFS itself provides. It’s particularly hard to reconcile the integrity requirements with the provision of editing functionality to a human user.
This is where IPFS comes in the game, playing with tiddlys and tiddlers in IPFS offers an underlying layer of data integrity.
The main idea behind @papiche project is to join all crypto apps in ed25519.
I wrote some crapy code to extract ed25519 keys from gpg and convert them between G1 (base58) or IPFS (b58mh) formats.
Having ed25519 sign, verify, encrypt, decrypt operations capabilities in a TW would be awesome
Edit: Something like https://tweetnacl.js.org/ ? or built in crypto library could already provides that through openssl support ?
When we could use “ed25519” key to “cipher or sign” “tiddlers fields values”, and “tiddlers”, it makes tiddlers being able to have a private or group diffusion among TW.
You’re right, any one could suffer a “code injection” or “hijacking” of it’s TW. But user is mainly responsible of it, mainly because of sweeping to copy an untrusted tiddler
That’s why, once the one TW, one Key, one People is an interesting feature established in the application.
This is the main trouble in a “peer to peer” application spreading, such App having no central point are empty rooms showing it’s magic only when users and data enters in it and make the keys interact (sewing blockchains from all)
I think, and are working on it.
TW is a great platform to demonstrate how ‘crypto’ could shape our ‘cyber-exchanges’ in “a crypto friends TW world”.
Now let’s see if G1Lib or GPG will be activated first.