You are reading content from Scuttlebutt
@enkiv2 %8WvGU/ADNup3nml+aT9+0zwH9702Pbi6mvyz7YXk2Oc=.sha256

Anybody else having problems with #manyverse recently? It was working fine as recently as a few days ago, but today whenever I open it, it crashes within a second or two, bringing up a bug report dialogue (which, when I fill it out, complains that there's no admin email associated with the app).

User has not chosen to be hosted publicly
@enkiv2 %alaZnyG2OYz44Cv045XBnkBI6xUgkfYWu6+3hN59rjs=.sha256

I'll file one tomorrow, unless something already exists. I can't provide much information (it's just an immediate crash on startup) so the odds that it'll be fixed if I'm the only one reporting it is pretty small tbh.

@andrestaltz %o2kjmZ9lsh7pBUJ26NFLHpP3lkVz3R/f4Z0bQRb2Djk=.sha256

I think the crash is this: https://gitlab.com/staltz/manyverse/-/issues/1518

Which is super mysterious, as far as I can see. Apparently ssbKeys.loadOrCreateSync fails because it the "load" part couldn't load the keys so it proceeds to "create" them but upon creation it fails because the keys already exist. So it means there is some kind of error to "load" them. But what's odd is that I didn't update nothing about this part of the code. ssb-keys remains at the same version. Overall the changes from 0.2109.4 to 0.2110.5 were not that much and shouldn't touch this part of the codebase. And hard to imagine that suddenly something went wrong with the secret file for lots of people at the same time. Really puzzling.

If someone likes puzzles, please help us debug this one.

@enkiv2 %hFbfMUCcMHI5gi3c/PqKqzcF6P4fkp8JU9B71TW6Ehw=.sha256

This looks like the same error, yeah.

@enkiv2 %JLD5cGxuUZ6AjwndFYp3i1xq6pEFyjNqfyN1p5VuRhU=.sha256

Did anything happen with the packaging maybe? Like, the absolute worst case scenario consistent with this behavior is if a placeholder secret file (ex., an empty file) writes over the user's existing secret on installation. It'd be worthwhile as a sanity check to make sure that the secret file of somebody experiencing this bug is valid & not malformed (though I'm not sure how to do it myself!)

@andrestaltz %Oq5OGGle7QyGDp057AW/AjkBOn/bNHxlcefm8ZRkb+0=.sha256

Thanks to the help of @Luandro Pàtwy,
who uses the -indie flavor, I sent him another APK to debug the issue, and here's what I learned.

ssbKeys.loadSync fails with an EISDIR failure, which means that the secret file... is a directory? How on Earth did that happen?

Anyway, one good info that reduces the mystery of this bug is that I realize that in the latest version, ssb-keys-neon (Rust) was replaced with the traditional ssb-keys (JS), and maybe there was a remote chance that ssb-keys-neon was saving a directory somehow. The other possibility is that I noticed there are duplicates of ssb-keys shipped in the latest version, because of transitive dependencies in the npm dependency tree. Maybe there's some kind of mistake due to that.

I hope someone has an eureka about this, even though it's Friday evening.

@andrestaltz %ZdofL+AGNP2fh2Zm07GF3I5yMZI/qOQLwFFj0pV9x2Q=.sha256

IT MIGHT BE THIS

https://github.com/staltz/ssb-keys-neon/pull/25

In js ssb-keys, loadOrCreate("/tmp/foo") writes the keys to the file /tmp/foo, whereas ssb-keys-neon (8.0.0-8) was writing the keys to /tmp/foo/secret.

That version of ssb-keys-neon was used in Manyverse 0.2103.5:

https://github.com/staltz/manyverse/blob/v0.2103.5-beta/src/backend/package.json#L47

@luandro %m5DuBCBkDufw6sQJFBGpkNEtzdfbTXveJ18VBhPJwK4=.sha256

FIXED 🎉 🎉 🎉 🎉 🎉 🎉 Great work @andrestaltz!

Join Scuttlebutt now