I would work with you on something Nostr related. However, all the ideas I have when I play them forward seem useless. I have yet to hit on any idea that is makes any sense.

The 1 time Nostr was more than social media to me was it allows me to keep in touch with a friend internationally without WhatsApp. It works amazingly well, just as good as WhatsApp at least for texting.

I liked your Cloud/calendar replacement idea. I would like to be less reliant on Google cloud.

For example, one worry I have is if saved Bitkey backup phrase is compromised on Google cloud. I would rather save it on a relay somewhere that I could retrieve with Npub.

For me right now Nostrs killer use case is simply as-is as a life enrichment tool. for example, finding new music totally enriched my life the last couple weeks. Before that it was more like life advice and philosophy.

And now some tech advice.

But I have no idea what to do beyond what Nostr can already do which is put humans in contact with one another in the cyberspace.

So yah back to where it started, no wiser, another minute down the drain. On this roller Coaster ride where the attendant isn't even a pretty face.

Reply to this note

Please Login to reply.

Discussion

yeah, business-social i think is where the money is. i mean, google, bit.ai, proton... they all seem to be doing a brisk trade. there was some gsuite competitor that recently got bought by Notion and rugged all the users, was extremely disappointing because what the fuck notion? buy a project out to shutter it??? that doesn't seem like a monopoly proxy antitrust case to me? lol

that's partly why i'm wanting to make it happen. build a toolkit so that they can't even take down their competitor with such blatant monopoly gangster shit.

i'm not going to do it with nostr proper tho. protocol is a raging tire fire. the number of moving parts in it is deceptive, a lot more than necessary, being what i mean by that. the way it ignores long established things like mimetypes and accept-encoding and suchlike. the unnecessary and complicated merging of a request/response pattern with subscriptions, the use of websockets when this is not necessary for request/response, the lack of search operators to exclude, i must not forget to remember the exclusion thing. i haven't designed the query syntax but i suspect i will just use graphql, or something like it, but simplified.