Nostr Web Client

Right, just trying to figure out what the ask of clients is going to be. So as someone wanting to post for the community I publish a "Targeted publication event 32222". The client will then need to do a lot of work it seems to parse the content of that event, check it against the community guidelines, and then return some sort of notification if it fails validation.

And before that of course the client UI to generate the targeted event itself (versus a regular note not targeted to a community).

Have you a wire-fame in Figjam or somewhere to show how all this flow would look on a popular client like Primal? Like all the UI elements and backend flows that are not already in Primal but would need to be in Primal this all to work.

Niel Liesmons 9mo ago

Video is easier for me 😉.

https://cdn.satellite.earth/5463c472b9c90a3d103e7c0088281525ce279f17e784e23ed6f6b55aa143c703.mov

1️⃣ What any App that adopts Communikeys needs (at the very minimum) is a "Share" screen that lets users target their stuff.

2️⃣ The clients don't need to check if it "follows Community Guidelines", that's a job for the community's set up. The clienst can however, see the pricing (and other conditions for each content type) in the #communikey creation event and use that in their UIs pretty easily.

3️⃣ The last step missing is the way for the community to send "a message" back, if needed/wanted

Reply to this note

Please Login to reply.

Discussion

Garbage nsec 9mo ago

Thanks for the video, design looks sleek.

So coming back to the example of the text-post-only community; I thought there might be front-end validation in some simpler cases like that, but if all handled by the communi-key then how would that work? The post gets sent and then it's the communi-key's main relay that has the logic to parse the post (does it conform to spec)? And if the main relay rejects the post because it does not conform to spec then that rejection is the basis for the validation-fail notification client side?

Just trying to figure out where the actual computation happens vis a vis screening the event content against the presumably machine-readable spec.

Niel Liesmons 9mo ago

Yup, doing that computation on the relay (+ maybe blossom server) front seems to be the best win-win imo.

Main relay does computation, rejects your targeted publication event (and doesn't store the actual event neither) and sends a message back to you "Sorry, this is not TXT".

That message can even be as simple as a reply on the targeted publication event (just thought of that).

Garbage nsec 9mo ago

Ah okay, cool, or I guess the communi-key npub could just DM you the notification (or an npub approved by the communi-key to send support DMs could).

On the screening side, I'm not quite sure how much screening logic a strfry relay can be set up to do before it starts to smoke. Or how a strfry relay can be integrated with an external service to handle heavier loads, via those policy plugins and stuff. I'm sure it's all doable though.

Niel Liesmons 9mo ago

There's already many relays that have their own policies built in.

There's one for 240 chars only, one for GM posts, one for posts with an 👀 reply on it by a certain npub.

So if that's all all possible and already active. I don't see the limit here. But I'm a noob on the relay side.

Niel Liesmons 9mo ago

DMs are the worst solution imo.

Garbage nsec 9mo ago

What else though I wonder? if the goal is to piggyback off of existing client notifications then the communi-key would have to trigger a notification via an existing pathway (replying to a post, mentioning in a standalone post).

>That message can even be as simple as a reply on the targeted publication event (just thought of that).

But if the failed-validation post never gets published then there's no post to reply to no? I suppose a communi-key support account could simply @mention you with a boilerplate "You tried to make a post that failed..." message, and you'd get notified that way.

Niel Liesmons 9mo ago

1) There's no need to piggyback off of anything, since this is a new thing that apps would integrate. Might as well go for the most elegant solution we can think of then.

2) Good point on the event not being there. As said, I just though of it. I you think of a great way, let me know. And again, it can be completely outside of the box of what exist.

Garbage nsec 9mo ago

How about this. Everyone who joins the community is assigned a personal bot, call it a concierge spot.

Niel Liesmons 9mo ago

DMs leave that option open, yes. (while visually it's just the Communikey contacting you)

And don't enforce it.

¡Me gusta!

Garbage nsec 9mo ago

When the person joins the community, the bot will spin up an account and greet them, hey welcome to the community!. When an event is rejected, the bot will explain to them what happened, (again this is just a mention, but the person can also follow the bot account for regular updates). The bot isn’t posting anything not directed at that specific individual. And when the person leaves the community, the bot will say goodbye and then take itself out of existence.

Garbage nsec 9mo ago

All via kind1 posts, no DMs

Niel Liesmons 9mo ago

Then I prefer the privacy and polyvalence of DMs

Garbage nsec 9mo ago

You could have each person decide if they want the bot to @ mention them in a kind 1 or just DM or both.

Niel Liesmons 9mo ago

Nope. I see no benefit in kind 1s, only downsides. It's public and bad UX. Messages make more sense.

Garbage nsec 9mo ago

It would encourage kind1 clients to get their DMS in order, that’s one thing

Niel Liesmons 9mo ago

I'm not counting on Twitter clones.

Chat = the universal UX you build out from

🌍 🔫

Niel Liesmons 9mo ago

Copying Twitter UX is an order of magnitude easier than copying Telegram UX.

Garbage nsec 9mo ago

*Concierge bot

Niel Liesmons 9mo ago

You're making me reconsider DMs actually, but not in the sense that you'd first imagine it.

Niel Liesmons 9mo ago

We need a general communication line between "You" and the "Communikey" for several things:

- The Communikey saying "We didn't accept this publication because of XXXX"

- The Communikey saying "We would like you to publish (target) your great article (about a topic we cover) here"

- You buying Products from the Communikey

So it might as well be DMs (spec wise) but it doesn't mean I have to display it as a completely different chat.

Niel Liesmons 9mo ago

Already have several options in mind for how ti fit it in the UI of the Community itself.

I like this idea. Thanks nostr:npub1hyxredcavc6ruqgsf4wf4hmakpwnvefmzaspl7dja6a2sxlx0q3sxwtqnx

Garbage nsec 9mo ago

Ah yes, just read this. This is what I first had in mind. And DMs are okay for this.

Garbage nsec 9mo ago

Trying to imagine some of the future passive aggressive DMs from the communi-key bot:

"Hi there, it looks like you just tried to post to the community from CLIENT. While there was nothing wrong with your post, unfortunately CLIENT is having some issues showing community content as desired, and so we've temporarily stopped accepting community posts from CLIENT. Our community can be fully enjoyed, including posting of all accepted types, in the following apps: OTHER CLIENT, OTHER CLIENT, OTHER CLIENT..."

Niel Liesmons 9mo ago

Computation on the hosting side = services that I can sell.

Doing it client side, breeds inconsistent experiences. And if there's one thing I can't sell, well, ... :winkwithtongue: