you can visit the following blogs for an example: ElectronicMonkey's blog or Jack's Blog

because I don't want flycat to be a property software, I don't want to introduce a database(which makes it harder to deploy and host your own flycat instance) in order to do that. so right now we use a very bad method to achieve this, but I think it will be alright since we will make it better after setting up our own relay(instead of a private database, which means an interoperable way to do things on nostr) or doing some code refactoring.

Since nostr is mostly gathered by Bitcoin folks, most people here might not have a good feeling about Ethereum or any "shitcoin". but I decided to experiment with such a new feature anyway, mainly for two reasons:

1. I find this Nip-111 solution(which is how this feature works) interesting on an account-control level and couldn't help to get my hands on it
2. To me, seems it doesn't do any harm to Nostr protocol and the current flycat user experience. if you hate Ethereum or any other shitcoin, you can close the window and abort reading this post now and it makes no difference on using flycat.

But the real reason I am experimenting with such a feature comes from one simple fact I believed, that is

Nostr is the future for social networks and it is how things are supposed to work and do right from the first day of the internet.

Of course, Bitcoin and the lighting network are the main motivation for building such a protocol at the first stage(which is currently where we are), but nostr is not only meant for Bitcoin people. it is for mainstream users and for people who don't even know about Bitcoin. that's the potential we saw from nostr.

With max simplicity protocol design(literally, there are only three parts of nostr: 1. public key as account id, 2. digitally sign content, and 3. relay-to-client mode), nostr is born to be the ultimate glue layer to connect to everything from centralized services like Twitter and Facebook to decentralized networks like bitcoin and lighting.

From this perspective, I believe it is worth exploring other blockchain spaces with nostr, demonstrating and telling non-bitcoin people how it feels to have a real social network binding with your crypto wallet.

How it works

This feature is done following the un-merged proposal Nip-111. If you want to know the workflow in detail, it is recommended to read the post written by the NIP authors.

Here are some simple explanations of how the Nip-111 proposal works:

since the Metamask and Ethereum blockchains use different crypto algorithms to do signings, it is impossible to use your Eth account to sign nostr stuff (unless Metamask and other Eth wallets support the Schnorr and Nip-07). But even if they did and we can, it is also not a wise choice to mix your blockchain key with the Nostr key since there are used for different scenes.

The Nip-111 solves this problem by proposing to generate a nostr sub-account (meaning a brand new key pair). The first step is using your Eth wallets to sign a fixed message to generate a fixed signature, and then take this signature, combined with the user password, to generate a new deterministic nostr private key.

To get this private key, you must be able to sign the message(prove that you are the owner of Eth wallet) and know what the password is(another proof). If the nostr key is exposed to hackers, it doesn't affect your Eth wallet account and your assets like NFTs or ERC20 tokens.

Risk and Downside

However, this approach does come with some risks and downside that you probably needs to know before using it. Even a nostr client(like flycat) doesn't store the generated private key from your Eth account, the Nip-111 required the client to hold your private key in the browser memory.

What this means is that every time you need to do something with write access on your nostr account(or export your private key), the web client will ask your Metamask or WalletConnect to sign a message to generate the private key and then use this private key to do the writing. during this process, the private key is accessible by the web client, which brings two risks:

1. you need to make sure the verify the integrity and authenticity of the web client you are using. Clients like Flycat are open-source and can be checked if it takes your private key somewhere else.
2. your private key is also exposable to the XSS attack during the generating process. This one is a real issue, and I don't see a clear solution besides making careful choices with which library to use and writing careful code in the web client implementation to upgrade the XSS defense. Considering there are still some people pasting their nostr private key to the web client to use the product, I will say this problem is as bad as that.

Why it is interesting

I think the Nip-111 is interesting not only because it can get Ethereum people to use nostr, but also because it is a pattern that shows how we can do account abstraction on all the other platforms. Besides Eth, all the other blockchains can create their nostr key using similar patterns. and maybe outside the blockchain space, we can also build it for centralized services to make people migrate to nostr.

Take Twitter for example, we can design a sign-in button that says sign-in with Twitter, and when people click the button, we let users post a private tweet that's only visible to himself/herself on Twitter, we take it with their password to generate a fixed nostr private key and let them start use nostr. after some time, the user might find that the nostr is great and decide to export his nostr private key and use the private key standalone instead of signing via Twitter.

Now you might think, there is a question with the above workflows: since Twitter is centralized, the private tweet is not only readable by the account owner but also by the Twitter company!

Yes, it is. That is why if the user decides to migrate to nostr seriously, he/she should consider generating a new key instead. But this is not a real problem in my opinion, because when you choose to sign in on nostr via Twitter, the implication is that you do understand the trusted scope is narrowed down to Twitter itself.

In another word, it means you choose to trust Twitter for such an operation, so if Twitter leaks your private tweet, it is not the nostr fault. The same thing also applies to Eth wallets. You trust your Metamask or WalletConnect has no backdoor to record and steal your signature.

Conclusion

I am really curious about whether Ethereum people will come to use Nostr or not and it depends on how they react to this experimental feature. If they want to taste a little bit of how nostr feels, they might choose to use it at some risk. and then make a new account when they get serious. or migrate to wallets like Alby that support Nip-07. If you have any thoughts, please comment on this post. We appreciate your feedback.

We also adjusted the layout of the editor page so you get less distracted in writing.

some meta datas will be displaying and required you filling only when you try publishing the post.

you can find your drafts on myBlog page (https://flycat.club/blog/ and continue editing it until you are comfortable to publish it.

As always, we appreciate your feedback. Please don't hesitate to tell me what you think about the updates~

tonight I just release the very first rough version of fly-castle, it is a very simple desktop app to provide a GUI for your own private backup relay written in Rust. the core relay implementation is forked from scsibug/nostr-rs-relay, I might touch the code there to experiment some ideas later.

Currently, I only build for macOS since that's the only OS on my laptop, but maybe I will find a windows computer to build windows one.

Here is how I would love to use it:

macOS

1. download the software from here
2. unzip it, you will get a file named fly-castle
3. create a folder named my-relay and put fly-castle into the folder
4. Start the relay by running the following command on your terminal:

cd my-relay
sudo chmod 755 fly-castle
./fly-castle

5. Open flycat website, click the private backup menu on the left side of the page. add the ws://localhost:8080 to your relay via the right side of the new page.

6. if you want to stop running your little relay, just close the window of fly-castle, it is that simple.

Headers

This is a Heading h1

This is a Heading h2

This is a Heading h6

Emphasis

This text will be italic
This will also be italic

This text will be bold
This will also be bold

You can combine them

Lists

Unordered

• Item 1
• Item 2
• Item 2a
• Item 2b

Ordered

1. Item 1
2. Item 2
3. Item 3
4. Item 3a
5. Item 3b

Images

Links

You may be using Markdown Live Preview.

Blockquotes

Markdown is a lightweight markup language with plain-text-formatting syntax, created in 2004 by John Gruber with Aaron Swartz.

Markdown is often used to format readme files, for writing messages in online discussion forums, and to create rich text using a plain text editor.

Tables

Blocks of code

let message = 'Hello world';
alert(message);

Inline code

This web site is using markedjs/marked.