Mauve 👁💜 @mauve@mastodon.mauve.moe

Brb running automated maintenance on my meatware.

(brb for dinner)

10/? Checking the code, there was nothing obvious. Adding a test, it seems to pass same as the SDK tests. It seems the bug might be somewhere in Electron or in Agregore's code. This means I need to start setting debug logs and breakpoints in the browser since my tests are non existent there.

https://github.com/RangerMauve/hypercore-fetch/blob/642a16b7551652f2afa08fb86e749d705ccab3d1/test.js#L653

9/? Trying to update the hyper-sdk tests to use drive instead of core isn't yielding the issue either. Maybe something in hypercore-fetch is adding more side effects than just initializing the drive? Gonna switch to hypercore-fetch and try to reproduce there.

https://github.com/RangerMauve/hyper-sdk/blob/d942fec959ef4f93cbab3a8a6e334d55ebce4cf5/test.js#L413

8/? This will then invoke the `createKey` function inside hypercore-fetch via the protocol handlers. Setting a breakpoint inside the scratchpad, it seems this function never resolves.

https://github.com/RangerMauve/hypercore-fetch/blob/5e237422362458f5baf410c21072eef3669ebe0b/index.js#L290

7/? The `showAllSaved` button uses the `hyper://` protocol handlers to resolve the local name `dweb_scratchpad` into a P2P archive URL using await fetch(`hyper://localhost/?key=${name}`, { method: 'POST' });

https://github.com/AgregoreWeb/website/blob/ce6ae7d4f590b1e80b2e059592930aa40a2f75e3/apps/scratchpad.html#L228

6/? I open a page I published using the DWeb Scratchpad and then try to open the scratch pad and click "Look at your saved sites", it doesn't open and the request appears to be frozen. If I open the site via the "Look at your saved sites" page before trying to access its `hyper://` URL it works fine.

hyper://agregore.mauve.moe/apps/scratchpad.html

5/? Reloading from disk also worked. Gonna get my reproducing steps clear within Agregore before I continue.

https://github.com/RangerMauve/hyper-sdk/blob/fix/remember-named-keys/test.js#L359

4/?

First test will just reuse the SDK instance in memory but try to clear the core data and reload it from storage by URL. Test passed so it might be due to loading the SDK from scratch from memory (is there a private key cache in corestore?).

https://github.com/RangerMauve/hyper-sdk/blob/c59a07cce7bd5d19140c5316fa76758428febc23/test.js#L334

3/?

Since the SDK is meant to work in both node.js and bare-kit, I'm using the `brittle` module for tests.

https://www.npmjs.com/package/brittle

2/? Step one: Reproduce the issue. I'll see if I can make a test to reproduce what I'm seeing in @agregore , but with the lowest level primitive I use for hypercore dev, hyper-sdk

https://github.com/RangerMauve/hyper-sdk

Gonna try something new. Live tooting my debugging session. Today's bug: If I open a `hyper://` URL that I should have the private key for without actually giving the `name` first, it won't generate the key and marks the drive as read only. Or something like that? #livedebug

My only complaint with head mounted display glasses is they don't seem to be made for people with large nose bridges

If open source biotech was a thing I'd totally install the equivalent of a new liver or whatever and deal with the debugging.

Fun fact: the only method I have to shut down my machine other than hard shutdown via the power button is to open a terminal and type "shutdown now".

Lol the default arch linux package doesn't run because of some sort of protobuf python bindings mismatch 🤷