Whenever someone says Microblogging is not the main usecase for Nostr, I want to remind you that the entire architecture was based on the needs of low latency public threaded discussions and fresh feeds.
If you gave up on that, at least take a chance and rethink the choices that was made and their cost. Can you simplify? Can you increase reliability? Can you gain more consistency? If you no longer face the demands that the protocol was designed to meet?
valid
1) How would you answer those questions. And what use case are we talking about?
2) I'm making Communities work and need relay IDs that don't rely on DNS. Can #pubky help with that?
1) I would obviously answer with yes to all these questions if I am building something that is more tolerant to small worlds and more similar to Matrix group chats, because obviously home servers work for that better, we saw it in SMTP and Mastodon and Matrix and almost all message passing architectures and they are plenty.
2) As you know I can't talk on behalf of Pubky anymore, but Pkarr definitely can allow servers to be accessed without ICANN DNS, that is one of the things Pkarr offer Pubky homeservers and possibly indexers.
But the other unasked question is are you actually better off with Nostr events over websocket queries at this point or are you better off with custom HTTP API?
If I had time (new job and quite busy) I would have worked on #mlkut more and offered everyone a complete solution for identity and key management, e2e encryption with minimal trust in servers, and an SDK to use that architecture to build whatever apps you want, it wouldnt give you a global feed and a fun playground of public data, but I established already that this is a non-goal.
While I can't speak on behalf of Pubky, I actually noticed they did some work to make it easier to run a proxy infront of arbitrary http servers and allow it to being accessed with a Pkarr key, including TLS.
That is good work and I hope people from outside the team notice it and leverage it, I wanted to build that myself and I am happy they did.
Oooh interesting stuff! ✍️
This is spot on. There's also the just-so-happens factor, for lack of a better term. A was designed to achieve B but it just so happens that A is actually a very useful way to achieve C.
C was never in the plans of team A, but hey, A achieves it.
If the just-so-happens factor is present then those looking to achieve C get the benefit of all the work and investment done by team A. If this work and investment is substantial then this can make A a great way to achieve C.
Lots of examples. Slack was designed as an internal tool for an indie game studio working on a goofy game called Glitch (screenshot below). Like that's all it was ever supposed to be for. But *as it turns out* Slack was very useful for internal business comms outside of any game context. That's how it goes sometimes.
