What timestamp do you need? Current time? 🤔

Since = Timestamp (not the created at) of the last event downloaded after the EOSE (in the live section of the subscription).

The Automattic vs WP Engine shitshow is another example of why nostr will win

Must read

nostr:note1eleqqfhcmgcd57x7g7s37jse7d7srumep4fgujhxu6a56saq3hyspcfhge

Poor man's poll: Is it

A) e-cash

B) ecash

C) eCash

D) none of the above

?

There was a study where people took turn ratings songs on a fake music review website, 1-5 stars. Each person could see the reviews from the people before them. Justin Bieber is widely disliked, but the study found that if the first participant rated the music highly, like 5 stars, it would continue to be rated more highly be other participants. If they rated him low, he would stay low.

The moral of the story is that an initial group of people can set the stage and perception of a thing, in the beginning. Right now it's Bitcoin. But Bitcoin isn't even that bad! Honestly it's one of the best online communities out there.

We need a few more nice communities like Bitcoin before we attract a mainstream audience.

I might be a little naive, thinking that anyone else might use a content search DVM I’m building for my own use, but I find the idea of interchangable microservices and cross-implementations fascinating.

Agreed.

I know it's not malicious on the part of any dev, but I've encountered several nostr apps prompting for signing multiple events of mysterious kinds.

Including events in a non-interactive context like loading a website an being asked for a signature.

Sign (or prompt to) events only when absolutely necessary. Be explicit about what's not obvious. Maybe we need work on UI/UX design around prompts?

nostr:note1tm93m6cvr2xpnafeschzsp7sgxurqszm0jzxrgar757eeuzanu0sqgv98e

The current proposal for DVMs has all the right parts already. Whichever DVMs answer your event, which describes your query, are the ones up and running. If you find any of them suspect, you can filter either on client or user level. We just don’t have enough of them built yet.

Odd question. Anyway that y'all could put together packages? That way morons like me could look for groupings of things to replace on our phones OS if not using graphene etc?

If you turn custom APIs into DVMs you can keep the relays as they are and also keep the interoperability while handling complex queries in any backend configuration you find suitable for a given task without prescribing anything.

"Relays should not be treated as databases" is silly and can kill nostr.

The relay query language was designed around a social notes client use-case. The "other stuff" that we love to talk about, as much as it's part of the nostr acronym, is an afterthought.

Other stuff clients do not work like social clients. They have way more specific requirements and hence need to use relays more like databases.

Since the query language is terribly limiting, this results in:

- Higher amount of requests

- More bandwidth

- More client-side processing

Do we want nostr to compete in terms of UX with other platforms/protocols or be forever lagging behind?

Worst of all, this leads developers to implementing hacks to perform queries (custom languages via NIP-50, for instance) which entirely defeats the point of a relay: to be easily swappable.

If we can't easily swap relays, nostr is dead.

The rationale for not treating relays as databases is based on the fallacy of simplicity. Since we want anyone (yes including your grandma) to create a relay we must make it as simple as possible – so we should not force implementation details such as requiring a database.

But guess what is the simplest way to build a relay? Using a database.

If we want nostr to succeed we must grow up, assume that relays will have a database backend, and reach consensus on a better query language that we're confident can be implemented in most engines (SQL, noSQL, graph, and so on).

Not perfection, not a highly complex language, but something that allows more flexibility than the archaic filters we have right now.

The " other stuff" in nostr are just different constructs of notes. If you're using nostr as simply a database for your app then you're just not aiming for real usage. But being able to interop through a common format in a well defined communication layer is the golden goose.

I agree. We don't need to put everything on 30382.

What we do need is to specify what the "service" is calculating so that the user can chose which provider of that calculation they trust and clients can know what the value means.

There will be some differences between providers, but the goal and the final result spec (type, range, tags, etc) should be just one.

Hopefully this NIP enables that multiple provider specification to come together.

I don't think this is optional for non-personal relays. They will have to grow up to use thousands of servers if they want to serve users globally.

The Client won't even know if it is an enterprise stack or not. It will just use the same interface we have today.

Nostr transmits notes and other stuff over relays. This is good. However developers are using nostr as a database. While, yes, you get a sugar-rush by doing so, this is non-optimal for several reasons:

- the content is only one field which is a text string, that is not easy to work with

- meta data is added to the content, but it is often misused

- the query languages is incredibly basic, worse that what existed in the 70s

- the database indexes are permissioned and centralized, it can take a year or to get approval to use an index

- a small number of developers get approval almost immediatly, the vast majority of innovation is kicked into the long grass

- the meta data violates basic computer science ideas of Entity-Attribute-value and has hard to work with array lists

- it is well-known for decades that connection-oriented networks dont scale

- the kinds (ie types) are rationed out by a central authority and no more than 100 are alloed

- entries such as profile are centralized, for example you are allowed one website, to do something like adding a 2nd website would be a multi-year project

- follower counts have to be added manually, so if you have a large number of follows then its impractical to make a query

This is not bad, because is shows that nostr can improve in many ways. But the first step is to acknowledge the limitations, before any of it can be fixed. Improving the devX would allow nostr to grow many OOMs.

Maybe I can search for bundles my follows are using?

Or just allow people to create their own bundles from apps they have installed + a few more they can dynamically add.