Nostr Web Client

If divergence in UX justifies divergence in data formats, then every distinct UX would have its own data format, and there would be no interoperability.

On the other hand if semantics justify data formats (e.g. we've arbitrarily decided that short form video vs long form video are different concepts on an ontological level), then divergent UX can interoperate.

The difficult thing is deciding what the trade-off should be between simplicity (by collapsing multiple types of thing into a single standard) and complexity (proliferating standards and granular tags for more complete support of more use cases).

The limiting factor is simplicity. Once a spec becomes too complex, the number of implementations drops significantly. Therefore, in order to support interoperability, applications have to interoperate on a level below their desired UX, and supplement either through inferring additional meaning from the base data formats (which logic may diverge between clients) or by creating proprietary data formats to support the client's UX.

Reply to this note

Please Login to reply.

Discussion

Alex Gleason 10mo ago

The answer: a mix of both

hodlbod 10mo ago

Yeah, obviously we can't go to ultimate simplicity or else there would be no information in the specs.

corndalorian 10mo ago

This is why I don’t think we need “Olas images” and “kind-1 images.” Let’s just have image posts, and each client can choose where/when/how to render them.

hodlbod 10mo ago

The difficult part is indexing them by type so you can fetch one without the other. If Olas fetches kind 1s, it has to filter out everything that doesn't fit the olas format. On the other hand, a client can support as many kinds as it wants. So granular distinctions are generally good.

corndalorian 10mo ago

It’s a shitty user experience.

hodlbod 10mo ago

What in particular? The re-posting via kind 1? Because I agree with that. But in any case I think clients can still provide a good UX by reconciling the different kinds when needed.

corndalorian 10mo ago

Reposting via kind-1 is horrendous and needs to be removed as an option in Olas. It creates unnecessary clutter/duplicate posts in clients that support both kinds. But also, I understand why people do it. Having 2 different event kinds for images now means the content you post is siloed, which is the opposite of how nostr is “supposed” to work.

I do see the use case for having a curated photo album for our nostr profiles, so in that way kind-20 can make sense, but only if it is broadly supported by clients. Right now it feels disjointed and not really that useful. And I hate the reposted kind-1 copies. lol

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

last paragraph is key

i think you can probably even propose a formula for sentences in the spec versus probability of X amount of implementations

this is also why i'm not even thinking about getting NIP "approval" for extending nip-98 to include JWT and adding the option of an expiry timestamp

because i'd rather negotiate client dev, per client dev, on this subject, so we can come to the nip-guardians as a group and say "we all are doing it, catch up"

Vitor Pamplona 10mo ago

You think "complexity" is "proliferating standards and granular tags". I think that is the easy part. Complexity to me is made by force-sharing and re-using incompatible but similar specs just to avoid duplication. That's the real complexity. Forcing existing kinds/content types that were not made for it into a given user experience. That's the real complexity. The number of NIPs is only a complex thing if your goal is to code all of them. If your goal is to just do one really well, then there is nothing complex about it. And most apps just need to do a few of them.

hodlbod 10mo ago

You're right, my use of simplicity/complexity is backwards according to Rich Hickey. What I meant was that proliferating standards make room for complexity within a single spec. Using a single spec for multiple closely related UX's forces the spec to not be opinionated.

My point is that "doing something well" is subjective. Two clients might want to do the "same" thing, but differently. This requires agreeing on a kernel data format and diverging in how those clients infer meaning from what is explicit in it. Like, instead of prescribing that every thread has to exist on a board, just let threads be their own thing — they can be organized by nip 51 list, topic, nip 29 group, relay, author, whatever. I don't think we should be over-prescriptive in specs, because ironically it introduces complexity as different clients try to bend the spec to what they want to accomplish. This results in combinatorial complexity. While if the spec is very minimal, yes there are limits to the functionality, but those are well understood and can be managed.

Vitor Pamplona 10mo ago

I think open-ended specs have let to the worst UX and most terrible use of Nostr. Kind1 is a good example. We never really defined it. And it took 2 years to create a kind just for replies so that we stop using Kind 1 in everything with lots of variations on what clients support and what users expectation should be.

To me interoperability is defined at the user level. Not only at the technical level. If I switch "video playing Nostr clients", I should not expect things to work and be interoperable. But if I switch a Shorts client by another Shorts client, then all Short videos better be there. The need for interoperability includes the semantical meaning associated with the type of content, not only it's functional underlinings.

Many data structures that are the same are not supposed to be interoperable at all. And I think we confuse that a lot on the NIP repo (myself included)

hodlbod 10mo ago

Kind 1 is ugly, but it's also the kind that has the most users by far. This is the value proposition of nostr. I'd take ugliness with interoperability over feature-completeness without interoperability any day.

> The need for interoperability includes the semantical meaning associated with the type of content, not only it's functional underlinings.

That's exactly my point. It's not about keeping specs DRY, that's insanity (in code as well as in specs). It's about optimizing for interoperability by focusing on semantics, rather than functionality.

Vitor Pamplona 10mo ago

I think that is the issue with 7D. It's too dry.

hodlbod 10mo ago

It's not DRY, because there's nothing to repeat. DRY is about code re-use. 7D is just a stub. I anticipate new tags, events, etc.

Vitor Pamplona 10mo ago

Sure, but if so what's the end goal for the 7D? If people already coded it, and the end goal changes, that might be a very difficult issue.

That's why I like vertical NIPs more. You set up the goal and layout the basics and within that use case framework everything can change as the implementers progress.

I don't think 7D can do BB boards and Slack/Discords at the same time. It just doesn't make much sense. The discussions on a BB are not chats and are also not threads. They are almost like Mailing list discussions (heavier content/message), but not quite.

hodlbod 10mo ago

Having something already implemented is a good thing. It forces a minimal kernel, with progressive enhancement. If that's impossible to accomplish the next time, sure, create a new standard. But ideally NIPs are extremely easy to support, with lots of optional stuff.

> I don't think 7D can do BB boards and Slack/Discords at the same time.

I still think you're letting existing products dictate what we're building. It's ok to invent new content types. What exists is a very small cross-section of what makes sense, and in many ways the wrong one (which is why we're here in the first place).

> The discussions on a BB are not chats and are also not threads. They are almost like Mailing list discussions (heavier content/message), but not quite.

I'm not sure what you mean by threads here, but I basically agree. BB-type "threads" were what I was aiming at with 7D. My goal is to have a non-chat place within communities where more substantial conversation can happen, not a twitter-post-type thing. I really think your spec is the same thing, just more developed, and of course with markdown support. But unless tables or your specific way of organizing content are essential for forum posts (I don't think they are) I don't think there's any incompatibility.

Vitor Pamplona 10mo ago

In the end, I think different BB forums will need different markdown supports. Coders will even need highlighted code blocks. A Scientific forum will need support for latex equations and maybe even full latex instead of Markdown.

So, even the kind I proposed will be broken down into other kinds later, when the need arises.

Similarly, I am sure there will be an AsciiDoc kind for BB systems as well as a BBCode kind in time.

Those are all going to be sub kinds into the same NIP for different BB systems that should not really see each other's data.

> On the existing products..

I like to talk about existing products exactly because it highlights how different things can be. And they already have product/market fit. So, it's less assumption, more reallife data. But of course, I support new products as well. They just need to prove they are what people want before spending too much time in it.

Niel Liesmons 10mo ago

The point of going for Asciidoc was to not have to bootstrap all this with 50 flavors of markdown.

I already have code block highlights in my renderer.

It's not that hard to have a satisfying standard for 80% of common use cases.

Beyond that I mostly need Communities to recommend apps that handle that standard well regarding their niche topic/goal.

Vitor Pamplona 10mo ago

Yeah, I don't see a future where we are AsciiDoc-only. Or any other format for that matter.

Different apps need different things. There is just no way around it.

That doesn't mean all apps must support everything though.

Each interoperable group of apps should pick the format that best suits them.

Niel Liesmons 10mo ago

I don't disagree long term.

I'm just not bootstrapping long form with 50 standards.

Asciidoc does it all for me, for now.

From there its market demand that will lead the way.

Vitor Pamplona 10mo ago

Long form was already bootstrapped with Markdown on NIP-23

Niel Liesmons 10mo ago

Design it first guys.

And start with the very basics.

I'm only designing + building for:

:thread: threads

:article: articles (priority to modular)

:wiki: wikis

:chat: chat

Until you have customers actually using your communities beyond chat and finding these textual content types lack something, it sounds very naive to start imagining all these extra kinds.