or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Feed Type Super Collider
Sometimes the best way to understand a system is to smash it into little pieces to see how it breaks. Instead of smashing particles together, this is an experiment in adding arbitrary feed types (like
.ed25519.superCollider
) and figuring out how that breaks the Scuttlebutt stack.ssb-keys
Done! Now we have feed types. Unfortunately this broke a few things in ssb-keys, but we can resolve those pretty easily.
Sweet. Now let's link it into ssb-db and test it out.
ssb-db
That was quick. Let's hop over to ssb-validate and see if we can wrangle the new feed type.
ssb-validate
Looks like this is failing here:
The problem is [probably] that
isFeedId(msg.author)
is failing because of our weird feed type suffix, which is checked by ssb-ref.ssb-ref
We can add support for the new feed type (and a test) with:
ssb-db 2
Let's link ssb-ref and try again:
Back to ssb-keys.
ssb-keys 2
ssb-db 3
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →It looks like
npm test
works now, which is great. Let's go up another layer and see what breaks.ssb-server
Our
ssb-db/util
hack doesn't work up here, so it looks like we'll need to dive back into ssb-keys to find a better solution. The first test is thebin.js
script, which seems to use ssb-config, so maybe we'll start there.Aside: ssb-server tests look like they're currently failing, so that could make this harder to debug.
ssb-config
First off, tests fail when another Scuttlebutt client is open in the background. Let's try again after Patchwork.
It looks like tests pass, and they still pass with ssb-keys linked, but I have a feeling that they aren't setting the ID correctly.
It's not very elegant debugging but it's fine for now.
It's a bit strange that some configs have the correct feed types whereas others don't. It looks like ssb-config is actually persisting old keys (!) to
~/.testnet/
(!!) which is allowing these tests to pass because they ignore the new ssb-keys we've created. After some shenanigans where I had to manually kill the server started by a test (!!!) I've finally got an error to work with:It looks like the test was crashing without closing the server, which is why I had to kill the process manually.
Not we can try again and we see the real error:
Looks like we'll need to teach muxrpc that it should use our public key rather than the feed ID.
muxrpc
ssb-config 2
Unfortunately it looks like our above change didn't do anything, because ssb-config depends on ssb-server for test (which is shinkwrapped and immune to linked dependencies). Fun. Maybe we can link in ssb-server and have muxrpc get linked from there.
It looks like ssb-config depends on an old version of ssb-server, so linking the new version just throws errors about plugins.
Time to update.
Looks like it works now, but muxrpc is just logging:
Fine. Let's spelunk a bit deeper.
muxrpc 2
The code seems to show that we're being authenticated as a stranger, which is weird because this is our server. The ssb-master plugin is meant to let the "masters" of the device into muxrpc, so it's probably not recognizing us because of the new feed type.
ssb-master
Sure enough, it's authenticating with muxrpc based on our id, not public key. It seems like really muxrpc should only care about signing keys rather than the feed identity and a feed type suffix, so maybe we can hack something together.
It still passes tests, and ensures that
@abc.ed25519
and@abc.ed25519.xyz
are handled as synonyms. A fewconsole.log()
statements are added for future debugging.ssb-config 3
Tests pass! Time to go back to ssb-server now.
It's important to remember that ssb-config only passes when linked to ssb-keys and ssb-server (which is linked to muxrpc and ssb-master).
ssb-server 2
Circular dependency time. We'll link ssb-config into ssb-server and cross our fingers that it's all handled correctly.
test/bin.js
failed the first time but seemed to work fine the second time, but the ID it output didn't have the correct suffix.Now it looks like ssb-plugins is throwing errors about a non-existent muxrpc file?
We don't need that module right now anyway, let's comment it out.
Also, since
compatibility
doesn't respect Ctrl + C it's worth removing it frompackage.json
right now. We want to be able to see test output and we can't do that if it's pumping text to stdout non-stop.Looks like tests pass!
Now to try
compatibility
… Hey, an error!ssb-invite
Looks like the tests are just broken though.
Anyway, removing that from the
package.json
tests looks fine, but now we have an issue with ssb-gossip.ssb-gossip