Charles E. Lehner

Could it help to change "Example 40: Usage of the nonTransferable property" to define notTransferable in the local context? Then at least the example would be closer to being valid...

I confirm this bug. Here is a verifiable credential using RsaSignature2018, generated using Spruce's [ssi](https://github.com/spruceid/ssi/) library [***Edit**: this library will longer generate a verifiable credential like this, as it will...

> during creation and verification of the RsaSignature2018 proof, you never actually serialize the entire VC (including the proof) to N-Quads as it is shown above in a few examples....

Hi @useaquestion, Nice progress on that. That connection rejection looks like #734. That issue is fixed in ssb-server v15.3.0 - not yet in v16. Does that work?

@useaquestion sounds like it may be a problem with your secret-handshake implementation. Are you able to connect from the same key using the `sbot` command? (or `sbotc` or go `sbotcli`)...

Why not update ssb-server to use db2? It previously had a migration process to use flume.

Hi @nichoth, Plugins specify permissions: https://github.com/ssb-js/secret-stack/blob/main/PLUGINS.md#pluginpermissions-object-optional To make a method public, it should be included in the `anonymous` array in the permissions object. e.g. the example in the above linked...

"Error replicating with ..." errors can be safely ignored. Although it is odd that it rejects `createHistoryStream` - maybe it is just doesn't do legacy gossip. I am considering this...

This looks good to me. But the package has been renamed from scuttlebot to ssb-server, so the snapfile should be updated accordingly. @skellat Re: https://github.com/ssbc/ssb-db/issues/188, https://forum.snapcraft.io/t/snap-wishlist-suggestions-wanted/567/344 Are you still interested...

Related issue on mx-puppet-slack: https://gitlab.com/mx-puppet/slack/mx-puppet-slack/-/issues/108