A weird idea but the more I thought about this the more I thought huh, maybe
- Special relay to which you write, perhaps you submit in markdown
- The relay renders to html and saves the post
- Relay also runs a web server, or saves the posts in a database such that a dedicated web server can retreive the file/post
The problems I see for this are:
- You would basically be reinventing tilde spaces, but with a submission interface over nostr.
- You would probably have to make this some sort of paid relay
- Multimedia attachment would be weird, it would definitely require a dedicated NIP to standardize in-band or out-of band attachments.
- Multimedia attachment would be double weird, as markdown et. al. isn't really a super appropriate or convenient medium to do that. You would probably need a specialized WYSIWYG (MS Word style, e.g) editor + nostr client to facilitate drafting and then submitting your posts over nostr
- at the end you would basically just have geocities/bloggr again, but with a weird nostr interface.
I think ultimately for all that work you would not have a thing that people actually wanted. It would be a lot like a nostr interface to a souped up twitter/or other microblogging service.
I've been pleased that the desktop client I've been using (gossip) is only using about 250 megs after a week or so of use. Granted it doesn't keep a global feed, just following, and whatever threads you expand/resolve. It has lots of jank though (no built in image display e.g.) but I rather like it that way.
My favorite part of my desktop client (Gossip) is that I cannot select and copy/paste absolutely anything. Instead I have a button to copy a whole message. Real lovely stuff.
nostr markov bot: the post
thou art an enormous bundle of sticks
Anything that properly implements the double ratchet protocol is probably fine bordering on ideal. XMPP's omemo is my preferred implementation and IM service.
Technically e2e encryption over email or literally any medium that can exchange text using AGE or PGP is also fine and fairly battle-tested.
Since none of those are peer to peer though, someone will always know you sent a message to someone else, but not what it entailed.
AFAIK there are no widespread p2p and e2e encrypted solutions, but maybe I'm just not plugged in to the right places
Embrace the jank, switch to a desktop client where webdevs mostly can't repeatedly shit in your mouth
Couldn't have happened to nicer people
As if.
I don't disagree with you but the solution is quite simple and not in any of the quesitons you asked.
Post no personal information, never use your name, your anything.
Use existing e2e encrypted solutions for "direct messages"
Don't be fucking retarded
This nostr shit is fine for what it is (public pseudonymous discussion) but it will fail miserably if idiots use it for something it isn't (social media for fucking cancerous e-celeb influencer wannabes sending you good vibes)
hence "incredible" as in unbelievable
litererally in-(as in not) credible
It is also incredible, in the more colloquial sense, because it's unbelievable that a real person could type this into a keyboard
#[0]
> wear glasses
> touch no part of lenses
> handle strictly by the legs and bridge
> lenses SOMEHOW smudge anyway
> big ass smudges, have to clean way more than I think I should
FUUUUUUUUUUUUUUU
(no this was not serious fuck you greenies)
Hot water is off, took the world's most efficient shower today. No hot water, half the water used.
Climate action NOW
zapping you rn babe, send feet
I think the fedi spec does attatchments pretty much right (except for the not so strict whether the key is always present when empty, whether it is a string, or an array, cause different implementations do it each of these ways because fuck you other server)
Relays not storing uploads as part of some in-band spec isn't a huge problem imo.
All you need is
- protocol extension to designate a url as holding an attachment (NIP, not hard)
- clients to allow you to configure what you use as the uploader (nothing really that can be enforced, hard)
the second part is harder because fragmentation. Maybe not everyone decides to play nice and allow you to set the place you are uploading. HTTP is probably the lowest common denominator for uploading/downloading attachments.
I think relays optionally running an http upload endpoint would be really cool because you could distribute where you upload to across many different relays. Then add a NIP to discover which relays you know about offer this service. I think this would be ideal.