I'm not sure our developers are treating relays as first-class entities.

Earlier today, as I was Jira mapping our Aedile dev kit project, I was thinking about how to structure the code. What are the first-class entities, and how should they be represented by the class structure?

I've come up with four first-class entities on Nostr, from the client's perspective:

1. Events

2. Relays

3. Users (npubs)

4. Subscriptions (event filters)

A well-designed client library should give all of these equal importance.

What does this mean?

Well, for example, I should be able do both event.send(myRelays) and relay.send(myEvent). It's up to me as the client developer to figure out which method best supports the kind of user experience I'm trying to create.

A social client might use the first method; the important thing is to create events and push them out over the network. What relays the events live on is less important than being able to chat with other npubs.

A relay-centric client, on the other hand, would use the second method. The priority here is to be able to view and interact with only the relays the user chooses, perhaps because each relay is a community, or different relays specialize in different event kinds.

Clients seem to focus on events, first; I have yet to see much development work on relay-centric UX. While this state of affairs persists, relays will remain underappreciated.