20%

That's massive

Hi all! Check out this Handy app https://github.com/cjpais/Handy - a free, open source, and extensible speech-to-text application that works completely offline.

I am using it daily to drive Claude and it works really-well for me (much better than macOS dictation mode).

Related, Using go fix to modernize Go code https://go.dev/blog/gofix

Here [1] is a related trick in the old Unix to run either `foo`, `/bin/foo` or `/usr/bin/foo` (apparently before `PATH` convention existed):

    char string[10000];
    strp = string;
    for (i=0; i<9; i++)
        *strp++ = "/usr/bin/"[i];
    p = *argv++;
    while(*strp++ = *p++);

    // string == "/usr/bin/foo"
    execv(string+9, args); // foo (execv returns only in case of error, i.e. when foo does not exist)
    execv(string+4, args); // /bin/foo
    execv(string, args);   // /usr/bin/foo

[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...

You can get yourself a vanity key using https://github.com/AlexanderYastrebov/wireguard-vanity-key tool:

   % wireguard-vanity-key -prefix=NAS/
   private                                      public                                       attempts   duration   attempts/s
   EiBsDB8zt/G4+VWGvxW2ZznNXYmcslcIyJimNR2PpF4= NAS/aex8+IFzLePBYVNGMsSo/1/XeUZcam+Hn8wbNB4= 22619537   0s         112587360

While it's cool, something about vanity keys in general stroke me the wrong way. I feel like in principle you should never use a very short part of a public key for ocular identification, and it attempts to solve something that should be solved outside of wireguard, i.e. the "friendly naming" of public keys.

Official stance about supporting interpreter mode for the reference https://github.com/golang/go/issues/24118

You can generate yourself a vanity .onion address using https://github.com/AlexanderYastrebov/onion-vanity-address tool. It can also generate vanity client authorization keypair.

Be careful with vanity address generators. A cryptocurrency market maker once lost around $160,000,000 in a vanity Ethereum address because the generator they used was only seeded with 32 bits of entropy.

https://www.forbes.com/sites/jeffkauflin/2022/09/20/profanit...

Indeed, be careful with anything that involves secret bits.

This tool uses proper crypto/rand initialisation of the starting key https://github.com/AlexanderYastrebov/onion-vanity-address/b...

Check out my other vanity generators (they all use crypto/rand):

https://github.com/AlexanderYastrebov/wireguard-vanity-key

https://github.com/AlexanderYastrebov/age-vanity-keygen

https://github.com/AlexanderYastrebov/ethereum-vanity-addres...

Unfortunately I got a hard crash on go 1.25.3 when running this: https://github.com/AlexanderYastrebov/onion-vanity-address/i...

WireGuard over WireGuard (WireGuard end-to-end encrypted hub and spoke) example https://www.procustodibus.com/blog/2021/12/wireguard-e2ee-hu...

  // hashItem computes the slot an item hashes to, given a total number of slots.
  func hashItem(item string, nslots uint64) uint64 {
    digest := md5.Sum([]byte(item))
    digestHigh := binary.BigEndian.Uint64(digest[8:16])
    digestLow := binary.BigEndian.Uint64(digest[:8])
    return (digestHigh | digestLow) % nslots
  }

Should be using XOR: (digestHigh ^ digestLow) % nslots

Thanks for spotting this, what a silly typo :)

... Fixed

Prefix check is a fast operation compared to candidate key generation so checking several prefixes adds a small overhead compared to checking just one.

Wildcard support has low value for the use case in my opinion, compare:

    helloyebjctfjivalxn343gppksrzdpm33qzmeeq4qnqwgrgqy75zoqd.onion
    qbtlzwabvvkvmogjy2wdvnn6gq55463jhellobwtnjsinvtxsur67oad.onion