2color

Regarding 2, we're actively working on radicle-artifact as an alternative to Git LFS with transport agnostic distribution (https/p2p), attestations, and redactions.

https://radicle.network/nodes/iris.radicle.network/rad%3Az4V...

radicle-artifact is currently under active development: https://radicle.network/nodes/iris.radicle.network/rad:z4VYy...

Radicle contributor here.

When a repository is initialised as private [1], it's encoded in the repository identity document. The only way to change a repository to be public is to update the identity document; in the case of a repository with multiple delegates (repo maintainers in Radicle nomenclature), such a change requires a quorum to be met. So I'd say it's more than a fat-finger away from leaking.

I was looking into how to get a radicle node running, but connected to only my own devices.

There's an open proposal [2] to introduce the concept of network configuration that would help with these kinds of use cases. Moreover, we're working on other ways to improve the collaboration experience for small teams, so stay tuned and thank you for this feedback!

[1] https://radicle.dev/guides/user#initializing-a-private-repos... [2] https://radicle.network/nodes/iris.radicle.network/rad:z3trN...

The general idea is using the radicle-ci-broker [1] to hook into repo events, and trigger different adapters based on the specific CI/CD tool you use.

We'll have more docs on this very soon. Also see https://news.ycombinator.com/item?id=48153535 for more info

[1] https://radicle.network/nodes/seed.radicle.garden/rad%3AzBNX...

What are you missing from Radicle today that would make you chose Tangled over it?

Same here. They've built an amazing toolkit that's such a joy to build with. Feels like game changer to have p2p that both reliable, fast, and fun.

I like that more people are thinking solving some of the problems of digital inheritance we face. These are problems that are so important now that so much of our lives are digital and tapping into ones actual social circle seems the best way to do this.

Also, kudos for packaging it as a static web app. That's the one platform I'm willing to bet will still function in 10 years.

same

I am sympathetic to the criticism of the naturalistic fallacy, however there are some aspects of modernity that are unquestionably toxic, like air pollution.

A good way to avoid the "how are you?" small talk trap, is to ask "how are you sleeping?"

There's a `loadOrCreateSelfKey` function which you can use to load the key from a persistent datastore (fs).

It's documented here: https://github.com/libp2p/js-libp2p/tree/4420fad686921f88785...

I'll be sure to update the docs to include an example in the config docs.

I wouldn't be surprised if it's built with Iroh

https://www.iroh.computer/

Same. It's much more customisable out of the box and has a lot of nice features.

It's a very exciting moment for this movement. A lot of the research and tech for local-first is nearing the point that it's mature, efficient, and packaged into well designed APIs.

Moreover, local-first —at least in theory— enables less infrastructure, which could reignite new indie open source software with less vendor lock-in.

However, despite all my excitement about embracing these ideas in the pursuit of better software, there's one hurdle that preventing more wide spread adoption amongst developers, and that is the Web platform.

The Web platform lacks building blocks for distributing hashed and/or signed software that isn't tied to origins. In other words, it's hard to decouple web-apps from the same-origin model which requires you set up a domain and serve requests dynamically.

Service Workers and PWAs do help a bit in terms of building offline experiences, but if you want users to download once, and upgrade when they want (and internet is available), you can't use the Web. So you end up breaking out of the browser, and start using Web technologies outside of the browser with better OS functionality, like Electron, React Native, Tauri et al (the https://userandagents.com/ community is doing some cool experiments in this space).

Fun read and great reference to Zen and The Art of Motorcycle Maintenance.

I highly recommend reading Lila, by Pirsig too!

Writing expands your working memory, lets you be more brilliant on paper than you can be in person.

So true!

Same here. It's the best smart watch I've had.

Sorry for misunderstanding.

I think the app was built on the assumption that someone is providing these CIDs.

My understanding is that IPFS always requires an IPFS → HTTP gateway to work in browsers, so I wonder what you mean by "P2P retrival in browsers".

By P2P retrieval, I mean retrieval directly from a peer that has the data without additional hops.

Historically HTTP gateways were the only way, because you couldn't dial (most) peers directly from a browser unless they had a CA-signed TLS certificate (needed in secure contexts.)

A couple of things changed that:

- WebTransport and WebRTC-direct allow browser-server(peer) communication without a CA signed certificate. WebTransport is very new and still has some problems in browser implementations.

- We just launched AutoTLS which help public IPFS node get a wildcard let's encrypt TLS certificate, making it "dialable" from browsers

With these, it becomes a whole lot easier to establish connections from browsers to IPFS nodes. But it takes time for the network to upgrade.

Note that Libp2p transports are wrappers over network transports to allow interoperability across runtimes, e.g. TCP, QUIC, WebSockets, WebTransport. These are not custom protocols.

Now you point about custom protocols, by which I presume you are referring to data exchange/retrieval protocols.

There are two IPFS data transfer protocols: - Bitswap: the first and default data transfer protocol which requires a streaming network transport (so HTTP isn't ideal). - HTTP Gateways: Initially, HTTP gateways were servers that would handle retrieval (over Bitswap) for you if they didn't have the data locally (sometimes we refer to these as Recursive Gateways, like trustless-gateway.link and ipfs.io). For all the reasons in Lidel's talk (caching, interop, composability), we extended this notion and made HTTP Gateway a general interface for data retrieval.

Today, there are large providers in the network (pinning services) that expose their data with an HTTP Gateway, which allows browsers to retrieve from directly.

We still have more work to do to expose the gateway in Kubo with the new AutoTLS certificate, but for the time being, Bitswap should work well enough even in browsers over a WebSockets connection. ---

Verified Fetch's aims to ensure you get data is it's available. If it fails to find a direct provider of the data, it will fall back on a recursive gateway like trustless-gateway.link which is configured in the defaults. As more IPFS nodes upgrade to newer versions, reliance on such centralised recursive gateways will become unnecessary.

TL;DR: We're all in on HTTP. The real constraint to P2P is browser vendors and slow standard bodies.

Small correction:

You can also pass [@helia/verified-fetch] gateways as a fallback for when it *cannot* connect to providers directly (due to transports).

It does require an IPFS node, i.e. server to provide tha data. The point is more that data isn't tied to any specific server. By content addressing with CIDs you can fetch from multiple IPFS nodes and even become a "provider" for a CID once your IPFS node downloads a copy.

With some extra config you can pass custom hashers.

Any reason you chose BLAKE2b-256?

BLAKE2/3 are amazing hashing functions and have a lot of cool properties, but they really suck on the web in terms of performance. This came up literally yesterday https://bsky.app/profile/norman.life/post/3lbw2qltokc2i and has been reported by multiple devs recently (who also shared excitement about BLAKE)

IPFS contributor here.

IPFS certainly has its flaws, but it's been getting much better in the last year. If you want to do P2P retrieval in browsers, it's practically the most advanced from all protocols.

We just published an update on this topic https://blog.ipfs.tech/2024-shipyard-improving-ipfs-on-the-w...

This looks neat!

IPFS contributor here.

I had a look at your code and saw how you handle downloading from multiple gateways.

There's a better way to this which also leverages direct P2P retrieval in browsers, which is now a thing with IPFS! [0] If you just want to fetch, checkout @helia/verified-fetch[1] which gives you a Fetch like API that accepts CIDs. It handles all the content routing and retrieval p2p magic and can help reduce reliance on gateways.

You can also pass it gateways in case it can connect to providers directly (due to transports)

[0] https://blog.ipfs.tech/2024-shipyard-improving-ipfs-on-the-w... [1] https://github.com/ipfs/helia-verified-fetch/tree/main/packa...

Have you looked at Luma?

That's a bit like saying that every public toilet that charges a fee is a scam. Surely there are scams and hype in this industry.

Fees are for inclusion of a transaction in a block. And some pretty clever game theory was implemented as part of eip1559 in Ethereum to make fees efficient and fair.

Thanks for making it Nicolas, All About Berlin is an immensely useful resource and has made the lives of so many newcomers to Berlin much easier.

beautiful website and nice overall aesthetic.

It's been fascinating watching Radicle evolve over the –what seems to be– last 5 years.

I attended the workshop at Protocol Berg 2023 and think they built something really powerful and novel.

Perhaps the most exciting aspect is that even the collaborative aspect of the protocol is local-first which means you can submit patches and issues without internet and that your team isn't on HN every time GitHub is having problems.

As someone who's been active in the IPFS community, it's really exciting to see how Anytype uses content addressing to manage and sync data under the hood (https://github.com/orgs/anyproto/discussions/15).

I think the fact that local-first P2P apps cannot be built directly on the web is a shame, some of the building blocks, like WebRTC are there, but browsers still lack some APIs to allow for more bottom-up innovation and experimentation with new protocols in the browser.