Someone should create a Nostr mobile app that's like a web browser. It has an address bar at the top, and you can enter npubs, nip05's etc to view a person's page. You could also view webpages hosted on Nostr (naddr?), as well as see previews for other types of events. This would be cool.
Soapbox local dev server running through Bun instead of Node.js.

That's a cute idea. Let them hit "Next" and then surprise attack with it, giving them a "Wait! I didn't write down my seed, go back" option
Could be solved with toggles that say "I have written down my seed", "I understand that I cannot recover my account without my seed", "I will not share my seed with anyone" etc before allowing them to click Next
Is this Safari? Some people mentioned z-index issues but I haven't seem them. I'm aware feeds are buggy. Once I wrap up Ditto stuff I'll be putting a lot of effort into Soapbox again.
I think BIP39 is a good UX that helps dumb down the whole thing, and by essentially making Soapbox an HD wallet it can open doors to other functionality and maybe help it support hardware signers in the future.
My plan for Soapbox + Nostr onboarding UX is to have it generate a 12-word seed on the client. You see it once and are told to write it down, then it disappears forever. It gets stored securely in the browser and can then be used to sign events. To recover your session, you need the 12-word seed.
This is the basic normie flow for mass adoption. There are other options, including NIP-07 signing with a browser extension like Alby, and NIP-46 support where you can sign events remotely using a dedicated signer app. You can also import by seed or nsec.
Technical info: I'm making the ServiceWorker a signer. You can send it messages like generateSeed, signEvent, decrypt, etc. When you generate the seed, the ServiceWorker generates it within the worker context and stores it in the Web Cache API. Which is an absolutely insane thing to do, but it will work. It sends the seed back to the client exactly _once_ when you generate it, and you can never retrieve it again because the worker will block fetches to it. But the worker itself can access it and sign your events. This is Vegan Mad Science.
Very cool. Google Forms alternative on Nostr: https://formstr.app/
nostr:npub1xrmj2tt4cht9tse4f4287en9g9xjwa9le0adnek60afvapeu5pqs6pdncv nostr:npub1znavx0efn9y7a9tjux6pchjdurmw2e84fxwxflmauupjz0558x0sqmwtpl nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1zx4nsay889fcjrlk0zmpywe9y7pz6fflphwdcyzkjad4hmyk09asw6s6fq
Perhaps try reading, you fucking idiot.
AABBDCA9-E007-467B-9A90-DA85B87705CA.jpeg
?name=AABBDCA9-E007-467B-9A90-DA85B87705CA.jpeg
It must be difficult walking through life so mad all the time.
It started with "I'm implementing media uploads and need to get a sha256 for the filename" which lead to "well, couldn't I get an IPFS CID instead?" which resulted in a defacto IPFS implementation in 5 lines of code, the dopamine was rushing, so I went a bit further. Now it's less than 100 lines of code for real IPFS integration as an option instead of just S3, which always felt wrong to me anyway.
While playing with IPFS, it occurred to me that Revolver is probably storing the posts themselves on IPFS, which is a pretty cool idea but I could imagine all kinds of problems. You can't exactly make it good unless you build a good IPFS implementation just for this purpose.
Pete is going to sue me for copyright infringement because we both implemented IPFS.
Decapitate a camel. Decapitate a lamb. Stuff 20 chickens in the lamb's ass, then stuff the lamb into the camel's ass. Boil in 100 gallons of water. And they say vegans are weird??

Ditto IPFS uploader and S3 uploader. I caved and decided to support both. The IPFS uploader uploads to a locally installed IPFS instance. The S3 uploader uploads to S3, DigitalOcean, etc. But even the S3 option has partial support for IPFS. In both cases media IDs are IPFS CIDs, and the media is made available at `/ipfs/


Sad.

nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1mh5a6mhm4u78glqxhltq7uexv6kddphycthlguvn0ux8ch72tc8q6q233h it's also a different scenario for me too because i literally have a file hosting service next door on pomf.lain.la. i can just tell users who complain to go use that and stop using the fediverse like a 00's DDL site.
Just write an uploader module that uploads Pleroma attachments to your pomf server.
Get this: the ipfs API doesn't even need credentials. You can just POST to it over localhost because it runs on a private port. You can literally install ipfs as a dependency and it "just works" with zero configuration for media uploads.
I put some evil code in there. What I'm actually testing is the alert popup.

Yep it's content addressable just like Nostr, so makes sense. But nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 hates IPFS because it's slow and unreliable. 😃