Update websites.json: add a Nostr client

[BlowaterNostr]

Describe the changes you have made in this PR

Add https://blowater.deno.dev/ to Nostr website page

Type of change

• docs: Documentation update

[reneaaron]

@BlowaterNostr Thanks for the PR! I just wanted to test this application but stumbled upon this hint:

Do you mind to explain what isn't working for you in Firefox?

[BlowaterNostr]

@reneaaron Will reproduce and give you a better report.

[reneaaron]

@BlowaterNostr Cool, thanks! 🙌 Feel free to open a new issue for that 👍

[BlowaterNostr]

Maybe it's not necessarily a bug of Alby. But the way my application is interacting with it. The direct observation is that Using Alby on Firefox with Blowater will trigger a null reference exception very deep in Preact's code with no call stack from application code. With the same code, but Chrome works.

[reneaaron]

Okay. Is the code available publicly? Happy to take a quick look...

[github-actions]

🚀 Thanks for the pull request!

Here are the current build files for testing:

• chrome.zip.zip
• firefox.xpi.zip
• opera.crx.zip

Download and unzip the file for your browser. Refer to the readme for detailed install instructions.

---

This build is brought to you by: channel.ninja (who recently dropped 1000 sats):

---

Want to sponsor the next build? send some sats to ⚡️builds@getalby.com (don't forget to provide your name)

Don't forget: keep earning sats!

[BlowaterNostr]

@reneaaron the code is not open sourced yet. I will consider it once it reaches feature stability.

[BlowaterNostr]

@reneaaron I have found the reason and it's a good indicator that Alby should support concurrent API calls or at least throw errors when user concurrently calls.

The story is this, in Blowater, we concurrently call encrypt/decrypt/signEvent/getPublicKey in many different promise chains. The current behavior of window.nostr is to simply return the result of the first call in the current JS tick. For example, if

getPublicKey()
encrypt()

are called in the same tick. await encrypt() will return the public key. Although in the log Alby gives a warning message, but the code behavior is not a good design. I would categorize it as either a bug or a design flaw.

I worked around this problem by adding a queue in my application code to wait for the previous call to resolve before invoking the next.

But, because Blowater also use IndexedDB, therefore, wrong data (should be an event, but was {enabled: true}) before I added the queue were persisted. I happened to never delete the database on Firefox, so that only Firefox appears buggy. I deleted the database and everything works now.

Fundamentally, TS is not type safe when it comes to serialize raw JSON to objects. Therefore, if application code always do type check during de serialization at runtime, this bug can be prevented. But this is not the norm in TS/JS code.

The communicate between extension and application is similar to serialization because it's also across program boundaries. We need better type safety here.

On Alby side, it should not return incorrect data (silent error) even if concurrent call is not allowed. Throwing exceptions is acceptable if concurrent call needs more time to design.

[reneaaron]

@BlowaterNostr Thanks for this detailed report, we're looking into it! I'll get back to you as soon as we have a fix for it ready to test👌

[BlowaterNostr]

#2218 does not block the development of my client, can we merge this first? @reneaaron

[BlowaterNostr]

Since #2218 is just merged, can we merge this now?

[BlowaterNostr]

@reneaaron

Blowater isn’t showing up. Is this because the action failed?

[bumi]

@BlowaterNostr you might stil be on the old version.