@mckinley@twtxt.net

HTTPS is supposed to do [verification] anyway.

TLS provides verification that nobody is tampering with or snooping on your connection to a server. It doesn’t, for example, verify that a file downloaded from server A is from the same entity as the one from server B.

I was confused by this response for a while, but now I think I understand what you’re getting at. You are pointing out that with signed feeds, I can verify the authenticity of a feed without accessing the original server, whereas with HTTPS I can’t verify a feed unless I download it myself from the origin server. Is that right?

I.e. if the HTTPS origin server is online and I don’t mind taking the time and bandwidth to contact it, then perhaps signed feeds offer no advantage, but if the origin server might not be online, or I want to download a big archive of lots of feeds at once without contacting each server individually, then I need signed feeds.

feed locations [being] URLs gives some flexibility

It does give flexibility, but perhaps we should have made them URIs instead for even more flexibility. Then, you could use a tag URI, urn:uuid:*, or a regular old URL if you wanted to. The spec seems to indicate that the url tag should be a working URL that clients can use to find a copy of the feed, optionally at multiple locations. I’m not very familiar with IP{F,N}S but if it ensures you own an identifier forever and that identifier points to a current copy of your feed, it could be a great way to fix it on an individual basis without breaking any specs :)

I’m also not very familiar with IPFS or IPNS.

I haven’t been following the other twts about signatures carefully. I just hope whatever you smart people come up with will be backwards-compatible so it still works if I’m too lazy to change how I publish my feed :-)

@prologic@twtxt.net Some criticisms and a possible alternative direction:

1. Key rotation. I’m not a security person, but my understanding is that it’s good to be able to give keys an expiry date and replace them with new ones periodically.

2. It makes maintaining a feed more complicated. Now instead of just needing to put a file on a web server (and scan the logs for user agents) I also need to do this. What brought me to twtxt was its radical simplicity.

Instead, maybe we should think about a way to allow old urls to be rotated out? Like, my metadata could somehow say that X used to be my primary URL, but going forward from date D onward my primary url is Y. (Or, if you really want to use public key cryptography, maybe something similar could be used for key rotation there.)

It’s nice that your scheme would add a way to verify the twts you download, but https is supposed to do that anyway. If you don’t trust https to do that (maybe you don’t like relying on root CAs?) then maybe your preferred solution should be reflected by your primary feed url. E.g. if you prefer the security offered by IPFS, then maybe an IPNS url would do the trick. The fact that feed locations are URLs gives some flexibility. (But then rotation is still an issue, if I understand ipns right.)

Can I rely on IPFS mirrors only yet for serving my personal static website? Probably only when you’re a popular IPFS oriented site.

So I should really try setting up a Restic repo on an IPFS/IPNS hash.

I feel like I only scratched the surface of what can be done with IPFS.

Mirroring my private sites on the IPFS network. Generating my static site using 11ty

Introduction · GitBook https://dweb-primer.ipfs.io/

GitHub - aurelg/ipfs-wormhole: Get things from one computer to another, safely. Over IPFS (which not even required to receive those things). https://github.com/aurelg/ipfs-wormhole

James Stanley - Someone used my IPFS gateway for phishing https://incoherency.co.uk/blog/stories/hardbin-phishing.html

I’m ambivalent about CloudFlare doing the IPFS gateways, but a lot of IPFS nodes are already running on AWS so I guess the ship has sailed on avoiding corporate data center creep in our p2p systems.

Take a look at pubsub on IPFS https://ipfs.io/blog/25-pubsub/

Bad idea of the day: Use ssb to coordinate pinning of ipfs objects

Bad idea of the day: A small dedicated machine (like a chumby, maybe based on the raspberry pi) that ships with ipfs & ssb/patchwork, casts from ipfs or peertube to TVs.

Against trendism: ipfs://QmQDqrz8Asn3wPbiTHFH9pyAXPNxwbeytJgzWUHF1PZup2 / http://ipfs.io/ipfs/QmQDqrz8Asn3wPbiTHFH9pyAXPNxwbeytJgzWUHF1PZup2 / gopher://fuckup.solutions/1enkiv2/medium-backup/2018-04-01_Against-trendism–how-to-defang-the-social-media-disinformation-complex-81a8e2635956.txt / https://medium.com/@/against-trendism-how-to-defang-the-social-media-disinformation-complex-81a8e2635956

Writing a Simple IPFS Crawler · Gokberk Yaltirakli https://gkbrk.com/2018/03/writing-a-simple-ipfs-crawler/

Metadata: Paper review. IPFS: Content addressed, versio… http://muratbuffalo.blogspot.com/2018/02/paper-review-ipfs-content-addressed.html

Bad idea of the day: Instead of ads mining bitcoins in your browser, they run IPFS nodes and pin arbitrary hashes in browser persistent storage then store them.

Bad idea of the day: mirror all google fonts on ipfs and then use an extension that rewrites the urls to use that version. Alternately: use an extension that downloads them via tor.

@kas@enotty.dk Now i’m really confused, is there anything special scuttlebut is doing over mdns? Because dat and ipfs both supports file sharing over local links.

@kas@enotty.dk Now i’m really confused, is there anything special scuttlebut is doing over mdns? Because dat and ipfs both supports file sharing over local links.

Although that would seperate the network in clients that can or can’t support some protocols. Not to mention if someone would mention me with my ipfs address and other with my http address

@kas@enotty.dk, @freemor@freemor.homelinux.net (re: finger) That’s another neat thing about twtxt, it totally independent of any transport layer. ipfs, zeronet, finger, as long as the protocol has an url we could follow the ressource.

Although that would seperate the network in clients that can or can’t support some protocols. Not to mention if someone would mention me with my ipfs address and other with my http address

@kas@enotty.dk, @freemor@freemor.homelinux.net (re: finger) That’s another neat thing about twtxt, it totally independent of any transport layer. ipfs, zeronet, finger, as long as the protocol has an url we could follow the ressource.

There are so many alternatives like ipfs or scuttlebutt, but i fear that we loose the simplicity of the old protocols. That in my mind is the main attraction of twtxt.

There are so many alternatives like ipfs or scuttlebutt, but i fear that we loose the simplicity of the old protocols. That in my mind is the main attraction of twtxt.

So, last #txtnish update for today: It supports subscribing to ipns:// and can publish your twtfile to ipfs. puh

So, last #txtnish update for today: It supports subscribing to ipns:// and can publish your twtfile to ipfs. puh

looked over IPFS - looks interesting - will give it a try to see how many other people are already using it.

http://ipfs.io/ I want to learn more - bookmark

But publishing takes a long time, maybe I fork a detached subprocess to handle that. Mhh. You’ve been warned. #ipfs

But publishing takes a long time, maybe I fork a detached subprocess to handle that. Mhh. You’ve been warned. #ipfs

Next task: Fetching twtxt files from ipfs without using the public gateway. And pinning subscribed files would be great #ipfs

Publishing to #ipfs now works reliable in #txtnix. You can find me at /ipns/QmZxsWLdxMcpb34qXtDyFAVtUDDm9Fp2G24NSjS8fGWBWY/twtxt.txt

Next task: Fetching twtxt files from ipfs without using the public gateway. And pinning subscribed files would be great #ipfs

Publishing to #ipfs now works reliable in #txtnix. You can find me at /ipns/QmZxsWLdxMcpb34qXtDyFAVtUDDm9Fp2G24NSjS8fGWBWY/twtxt.txt

But boy, ipfs name publish really takes its time to find other nodes #ipfs

#txtnix now has minimal support to add and publish files with IPFS. Subscriptions shouldn’t be too hard either.

But boy, ipfs name publish really takes its time to find other nodes #ipfs

#txtnix now has minimal support to add and publish files with IPFS. Subscriptions shouldn’t be too hard either.

Testing the ipfs backend … nothing to see!

Testing the ipfs backend … nothing to see!