Ah lol, of course 🤦.
I just typed n o s t r : n e v e n t 1 b l a b l a . . .
But this makes my point even more obvious :haha:
So are nostr event quotes allowed? Emoji? etc... ?
Or is Text = TXT ?
Discussion
Ah hah, lol. That's a whole 'nother problem.
Pure text. No links. No emojis (except I guess those Japanese ones you make with pure text.) Kind1t notes can quote other Kind1t notes, but that's it, can't quote anything that isn't also a Kind1t note.
But still zaps.
That'd be the dream.
If people need to share links, photos, gifs, they can jump back to their regular Kind1 client and share with the person there. This would be a hardcore enforced text-only world.
Just realized that even just having a community that is intolerant of anything but TXT, would already be sufficient.
From the moment the #communikey can send some kind of message back to you with:
- We don't accept that here
- This is why we don't accept that here
You can do some pretty cool things, without apps like Zapchat having to specifically be coded for it.
You can literally have a community (with its main relay having some automation probably) that only accepts Chat messages that are "GM", , etc...
How would cross-context communities work. Let's say you've got a group, you can link up with that group on Primal or Jumble, where you talk about some subject, but you can also link up with the same group in a chat app (community channel), or even a shopping app (community discounts), or a gaming app (play with each other) etc. In each context the nature of the community changes.
Nope. The nature of the community stays the same, that's the kinda the Value prop here.
You define it as:
"We are this community, that works with these content types (chat, games, products, ...), with these conditions, ..."
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.
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
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.
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).
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.
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.
DMs are the worst solution imo.
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.
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.
How about this. Everyone who joins the community is assigned a personal bot, call it a concierge spot.
DMs leave that option open, yes. (while visually it's just the Communikey contacting you)
And don't enforce it.
¡Me gusta!
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.
All via kind1 posts, no DMs
Then I prefer the privacy and polyvalence of DMs
You could have each person decide if they want the bot to @ mention them in a kind 1 or just DM or both.
Nope. I see no benefit in kind 1s, only downsides. It's public and bad UX. Messages make more sense.
*Concierge bot
You're making me reconsider DMs actually, but not in the sense that you'd first imagine it.
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.
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
Ah yes, just read this. This is what I first had in mind. And DMs are okay for this.
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..."
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:
Btw: I don't see Primal adopting this any time soon.
Buuuut, the cool thing is that any* posts created in Primal in the past (and future) can still be targeted to Communities with any apps that integrates #communikeys.
* given that that post doesn't do any of the weird spec disrespecting we often see