🔴 What Is Islam? 🔴 Islam is not just another religion. 🔵 It is the same message preached by Moses, Jesus and Abraham. 🔴 Islam literally means ‘submission to God’ and it teaches us to have a direct relationship with God. 🔵 It reminds us that since God created us, no one should be worshipped except God alone. 🔴 It also teaches that God is nothing like a human being or like anything that we can imagine. 🌍 The concept of God is summarized in the Quran as: 📖 { “Say, He is God, the One. God, the Absolute. He does not give birth, nor was He born, and there is nothing like Him.”} (Quran 112:1-4) 📚 🔴 Becoming a Muslim is not turning your back to Jesus. 🔵 Rather it’s going back to the original teachings of Jesus and obeying him. More .....👇 🔴 THE RETURN OF JESUS

What Is Islam?

بسم الله الرحمن الرحيم 🔴 ATHEISM EXPLAINED IN 45 SECONDS https://youtu.be/uwqPdWZvjAY 🔴 "ATHEIST VS MUSLIM (PLAN...

I'm down.

Id be interested

While we are at it, maybe, just maybe, add a flag for signer side publishing

My defense for why this is necessary: Because i can effectively do it now, and it will work, other than that clients get confused. (The signer refuses to respond to the client on a sign request, but does sign and publish the event itself, client will throw an error, note get published all the same....so lets just remove the error)

I'd be down

This is why we need to experiment and stress test the nip. I support 🤙

LFG! 🚀🌙

Here 🙋‍♀️

I thought about this more… @Clave and other signers should only be publishing the kind:24133 RPC event, not the signed event itself. Have you seen a signer in the wild publishing as well? You're basically talking about a signer offloading the signing AND publishing responsibilities from the client. Some clients might want this — e.g., if the signer manages the user's NIP-65 outbox, the client wouldn't have to worry about relay management. Would essentially be a new sign_and_publish RPC method. Worth discussing and/or experimenting during the nip46 hackathon.

Well said ser 🤝

🙋 count me in!!

nostr dot report (from your profile text) is unreachable.

That one’s been gone a loooong time…

Never truly gone. The nsec lives on…

I like the idea. And I did build full support for remote signers into applesauce, so maybe that would make it easier?

Nostr Connect | Applesauce

Nostr Connect signer implementation for remote event signing via relay communication

Applesauce Examples

yes, i am indeed talking about offloading publishing as well. Its not just for the client's sake, but more so the user. I have a need for this within TEPP, where permissions dictate to what relays things are supposed to go; the TEPP engine can run inside the client as well, that is all fine and preferable for a bunch of reasons, but if it doesnt there is no way to enforce things. But my main argument here is not any use justification really, my main argument is that with signer, i am in the position to ignore a client, publish it ''myself'', get an error from the client, but still have the event pop up. Ergo, the spec should simply allow for a flag to settle expectations to avoid this error.....because you cant stop me from doing what i am going to do, which at the end of the day works, despite the now meaningless errors. Now it could be a different spec all together, that also handles query construction, basically turning the ''signer'' into a full client but without any render capabilities (reducing the user-apps into render-boxes). Based of off this ''NIP'' both the input and output (and as a result also the signing) could be offloaded completely. This way we dont have to touch the remote signing standard (it would simply be a more fancy standard replacing it)....but.....since its just 1 stupid flag for clients to not expect the signed event back, i'd say it worth it tackling this aspect directly in the remote signing stuff

down