Hi Jim One option might be to use the built-in Stanford JavaScript Crypto Library that we use for handling encrypted TiddlyWikis:
http://bitwiseshiftleft.github.io/sjcl/ It works in the browser and under Node.js. You can call it like this: var sjcl = $tw.node ? require("./sjcl.js") : window.sjcl; var myHash = sjcl.codec.hex.fromBits(sjcl.hash.sha256.hash(myMessage)) Best wishes Jeremy On Tue, Dec 23, 2014 at 9:00 PM, Jim Lehmer <[email protected]> wrote: > I am working on my Atom feed exporter, with the hope of eventually making > it a plugin. Right now it works using the *rendertiddler *command under > node, and in fact is depending on a node library (crypto) being in place. > This is because the Atom spec <http://www.ietf.org/rfc/rfc4287.txt> > requires an "id" (a GUID) for each article (tiddler) in the feed: > > 4.2.6. The "atom:id" Element > > The "atom:id" element conveys a permanent, universally unique > identifier for an entry or feed. > > ... > > When an Atom Document is relocated, migrated, syndicated, > republished, exported, or imported, the content of its atom:id > element MUST NOT change. Put another way, an atom:id element > pertains to all instantiations of a particular Atom entry or feed; > revisions retain the same content in their atom:id elements. It is > suggested that the atom:id element be stored along with the > associated resource. > > The content of an atom:id element MUST be created in a way that > assures uniqueness. > > > I decided to use an MD5 hash of each tiddler's title to generate a 128-bit > hash, which I then format into a GUID. It works quite well, and I think for > most foreseeable cases satisfies the spec. I did some research and then > decided to use node's crypto package, since it had an implementation of MD5 > with an easy API. All is good. > > However, when I *browse *to my TW (the original, not the generated static > output or feed) as opposed to running *commands *on it under node, it > gives an error at start-up in my module which ultimately I traced down to > the require("crypto") statement because node's crypto package is not > available when running in the browser (which makes sense). I could probably > do some work in my module to try and detect whether it's running in the > browser or under node and just export an empty *run *method when in the > browser environment, but that would invalidate one of Jeremy's wishes, > which is ultimately to be able to generate a feed under a browser-only TW. > > So, I see a few possibilities, and want to ask which way is the TW way? > Jeremy, I'm especially looking from feedback from you on this. I have this > specific use-case, but am also interested in general to the TW approach to > external dependencies and libraries. > > 1. Figure out another way to reliably generate those GUIDs in a repeatable > manner (same tiddler always gets the same id). Definitely doable, but I > hate reinventing wheels. > > Pros: Eliminates external dependencies. > Cons: Reinvents wheel. > > 2. Copy in the appropriate pieces of the node code or someone else's open > source implementation (with an OSS license that explicitly allows that - > node's seems to), presumably into TW's crypto module. > > Pros: Wheel already invented, TW's crypto module probably needs some > expansion over time anyway. > Cons: Still maintaining another copy of code, "cut & paste" programming at > its worse, with all that implies, including maintenance in case of bugs > upstream, etc. > > 3. Build TW with the node crypto module included somehow - waving arms > here a bit. > > Pros: Wheel already invented. > Cons: Requires node, but that's already a requirement, anyway? > > 4. ???Something else??? I note that the *utils *module has a *hashString > *function > exported, but it's only a simple 32-bit hash with high possibility of > collisions. It looks like TW2 had SHA1 hashing code, but (a) that appears > to be unused except for creating a "classic TW" edition, and (b) that's a > 160-bit hash, not the 128-bits I would need. Other possibilities? Something > I'm missing (likely)? > > Comments and discussion appreciated. > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/tiddlywiki. > For more options, visit https://groups.google.com/d/optout. > -- Jeremy Ruston mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
