You're right, it wouldn't be a problem because the local node would have all the files locally, and the URLs would all point to the local http gateway instead of an actual ipfs URI (we'd include the cid in API responses so you could resolve over ipfs if you wanted to, tho).

Users could also choose to disable remote ipfs lookups in the gateway for security/bandwidth reasons, but in the ideal end state we wouldn't even need a media proxy because the local gateway could resolve remote content.


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


S3 is one-click to provision a bucket, but good luck actually configuring it if it's not really S3. DigitalOcean, Wasabi, Minio, are all different and would need separate instructions in the install guide for how to configure them. The S3 API itself is an insane overly-complex unmaintainable nightmare, only made better by the various libraries that obfuscate how bad it is.

IPFS looks like it's just one REST endpoint with auth. I think you can just apt-install it and grab a token. But I haven't actually gone through it myself yet, so I might be missing something.

IPFS is more resistant to censorship and resilient, in theory, assuming it will actually resolve your file. S3 is reliable with better scaling capabilities.

I'm going to play with ipfs a bit more and see how much it struggles.


Because of the reliability and CDN support?


So should I make Ditto upload to an s3 compatible bucket or IPFS? I kind of want one way of doing things for the first release before adding configurable media stuff.

S3 means you need to run Minio or a cloud service. Ipfs means you need to run a local ipfs gateway.

I'm not gonna support local file uploads. Ipfs would be the closest thing.


Whether IPFS is slow or not, I think the CID is a fundamentally good idea.


I really hope the ADL ceases to exist.


They actually implemented ActivityPub.


I would never call you under any circumstances.


It's not like he was the first to ever think of it. I needed to implement media uploads anyway, it takes 0 extra effort to get the CID instead of the sha256, so why not. I wouldn't do it if it wasn't easy.


I accidentally built Revolver.


So in other words, Ditto will support media files over IPFS. In fact it's already done.


This is not even an IPFS integration. It's the bare minimum to enable other tools to integrate it into IPFS. There's basically no downside, I just get the CID instead of the sha256 (and the CID is not more computationally expensive - it just gets the sha256 under the hood). So you just do that and put it at `/ipfs/` and boom, you support IPFS without really supporting IPFS.


TIL simply having a path like `/ipfs/<cid>` will make Brave pick up on it and offer to open it in IPFS.

https://ditto.nyc3.digitaloceanspaces.com/ipfs/QmdrD5Z7EH3i9fzFpjYsrGWwMTkPUZW74FvwQXf1JgVMkU

https://media.gleasonator.com/6026ce40e02cda3bbd0a64db7e68014b3104f61f92318bbffc4e58908015ec90.png


It's not a gateway yet, I'm just using a CID instead of plain sha256 so it could enable ipfs features later.


I'm testing an idea where Ditto uses an IPFS CID in media URLs. https://ditto.nyc3.digitaloceanspaces.com/uploads/QmdrD5Z7EH3i9fzFpjYsrGWwMTkPUZW74FvwQXf1JgVMkU


See: https://gitlab.com/soapbox-pub/mostr/-/issues/44


https://fe.soapbox.pub

It's better if you run a development copy of ditto, the one on ditto.pub is unusable. Latest dev branch is almost usable.


https://gitlab.com/soapbox-pub/ditto

Still not ready for prime time quite yet.


Prepare to cry. https://youtu.be/494Wr7On6bA?si=ay5mV_7KgArhOCrc


nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 check out my NIP-98 parser.


Yep. 👋 DMs don't work, though. It just goes into the void.


That's exactly what Facebook is hoping for, and the reason they haven't pulled the trigger on federation.


Indeed. I'm chatting with Nostr users every day through the bridge and it's working pretty well. It will only get better with Ditto. But Nostr clients need to do a better job about discovering relays automatically and using them to find content. Mostr only posts events to 3 relays, and very few clients deal with that appropriately.


This is weirdly reminiscent of Monster Rancher for PS1:

>Although it is possible to acquire a monster in-game, the series is known for the ability to acquire new monsters using Compact Discs (CDs). Players can use any readable CD, and the game creates a monster using the CD's metadata.[6] Certain CDs would result in unique monsters: for example, Tecmo's Deception gives the player Ardebaran, a villain from that game,[7] and some Christmas music albums will give the player a monster of type "Santa".

https://en.wikipedia.org/wiki/Monster_Rancher_(video_game)#Gameplay

Maybe this idea is a catalyst for something else.


That is fascinating. https://github.com/simdjson/simdjson

If you're trying to get sub 100ms responses I guess you go out of your way to complicate things, but users are willing to wait a couple seconds for your shit to load as long as you give them a nice loading skeleton. You can get away with a lot if you do that.


Is this for real?


Exactly. This is what Mastodon does for trends and I copied it in Ditto. It counts the pubkey usages, not total usages.


As long as Spinster is on Rebased, it will be maintained. Spinster may even stay on Rebased forever, and so Rebased wouild live forever. But Ditto will have all the cool new features, so I think people will want to be using it once it gets there.


The bridge has to work with everything, so it chooses the lowest common denominator, which is Mastodon. Our software could be patched to improve the situation, and I have already done so by truncating the names in Soapbox. Patching it on the API side would require a lot of work I'm not sure is worth it opposed to just building Ditto.


This is a deficiency of Mastodon, not Nostr. It is necessary for supporting the legacy Mastodon network. When viewed through Nostr most people have usernames.


CSP is a header in the HTTP response called "content-security-policy"

You can see it by running: curl -I https://blimey.social

Run: curl -I https://gleasonator.com

Compare the content-security-policy header.

You will see the "style" section is different. Mine allows unsafe-inline, yours allows only a single nonce

You need to make it return the correct thing. You can also check the console logs in the browser to see the errors resulting from this.

Paste your Nginx file into ChatGPT and ask how to do it.

I don't want to write up specific instructions on this because I don't want to encourage other people to do it. It's not a good thing. Akkoma has broken support for other frontends. This is an Akkoma problem.


Ah the great master race.


They would have to get a follower from Nostr first or reply to a thread with Nostr people. So in general, yes.

Also, you can see my view of your post here: https://gleasonator.com/@8eef5a3bf5e178356a0633b16f91c822f557c14d05a7adb21ca522f54dcc0136@mostr.pub/posts/AYs0c6UXJ5B9n3xd5s


No.


Thank you friend! You too.


Hey guys, I was featured on the latest Thank God for Nostr podcast where we discussed veganism, my beginnings at Truth Social, ActivityPub, and the move to Nostr.

Give it a listen here: https://fountain.fm/episode/7IvgMxBTfPXPw6CI60Oc

Thank you nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn for the great interview!


Thank you for having me on! Wonderful discussion.


Mastodon has been trying to do privacy features like this forever. It's the reason they don't have quote posting yet. They want to limit who can reply to a post. Something that goes against the grain of decentralized social networks.


The second best way is the kind 10002. But I wish the relay URL was on the kind 0. The kind 10002 seems like it requires activism to make people adopt. I needs to be a more ingrained part of the protocol.


You can reverse lookup a pubkey by finding a kind 0, getting the NIP-05 and then doing a NIP-05 lookup to get the relay. Don't shoot me.

nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn


Bath & Bodyworks Rose Water foamy handsoap reminds me of a time when I was very production, so whenever I use it the neurons start firing again.


Nihongo, gakusei


Linus Tech Tips is spiraling.


This project collects hashes, voted on by users. According to the IWF even holding the hashes is illegal... and I don't know about the concept of voting.


Wow! This is the first I'm hearing of this.


If your server is not on at least one fedi blocklist, it's basically not even real.


I think we could probably do a native Android thing. See: https://github.com/GoogleChromeLabs/bubblewrap

But I wouldn't want to do that. You should eat your own food and make the PWA app store a PWA.


That's actually a pretty great idea. The main challenge is that you can't install a PWA from another website. So 1-click installs wouldn't be possible.

You could still have a PWA marketplace in a PWA, but it should come with good instructions about how to install PWAs. Users would have to navigate directly to the website and then install the PWA through the browser's UI.


Deno is superior. It implements web standard APIs like SubtleCrypto and Fetch, making your code compatible with web browsers. It's also significantly faster than Node.js. It's a rewrite in Rust created by the author of Node.js to fix all the problems he sees with Node. Oh also, you can import stuff by URL. It's decentralized coding! The only reason to use Node.js is if you're relying on legacy code.

For anyone running Node.js who wants to use the strfry-policies code directly (as a library), I'm also transpiling it to a npm package with polyfills: https://www.npmjs.com/package/strfry-policies