[HN Gopher] Willow Protocol
___________________________________________________________________
Willow Protocol
Author : todsacerdoti
Score : 339 points
Date : 2024-01-17 12:27 UTC (10 hours ago)
(HTM) web link (willowprotocol.org)
(TXT) w3m dump (willowprotocol.org)
| catapart wrote:
| So this is pure spec? No implementations at all?
| castles wrote:
| https://willowprotocol.org/more/projects-and-communities/ind...
| nathan_phoenix wrote:
| Still confused to be honest...
|
| What does it mean that Earthstar will become a Willow
| protocol? Isn't it an implementation of Willow?
| m3talsmith wrote:
| There are at least two implementations there on that page:
|
| - One in typescript - One in rust
| candiddevmike wrote:
| A spec without an implementation is a lovely idea at best.
| rklaehn wrote:
| iroh developer here.
|
| willow was not developed in a vacuum.
|
| the willow folks have worked with us while we have
| implemented many ideas from willow, starting with range based
| set reconciliation ( https://arxiv.org/abs/2212.13567 )
|
| they have been open to removing parts that have turned out to
| add too much complexity to implementations.
| b_fiive wrote:
| iroh documents are a work-in-progress implementation of willow:
| https://github.com/n0-computer/iroh
|
| We've been working with the willow team as we go & giving
| feedback on the spec.
|
| disclosure: I work on iroh.
| elmolino89 wrote:
| The iroh name resembles a bit iRODS, another system for
| distributed file sharing and fine grained permissions.
|
| Quick googling did not give me a proper grasp of the use
| cases for iroh/IPFS vs iRODs.
|
| Would you be willing to list the benefits of iroh vs IRODS?
| b_fiive wrote:
| wow, thank you for pointing me to IRODS, I was not aware of
| the project! Big difference I'm seeing as I read the docs
| for IRODs is a datacenter-grade data management _service_,
| whereas iroh is a multiplatform SDK for building your own
| applications.
|
| Seems like one would want IRODs if they have massive
| amounts of highly sensitive data that needs fine grained
| access control. You would want iroh if you're building an
| app that uses direct connections between end-user devices
| to scale data sync
| rklaehn wrote:
| I was not aware of iRODS.
|
| Iroh is named by a certain fictional character that likes
| tea. Any similarity is a coincidence.
|
| But it seems like iRODS is much more high level than iroh.
| E.g. iroh certainly does not contain anything for workflow
| automation. You could probably implement something like
| iRODS using iroh-net and iroh-bytes.
| jw_cook wrote:
| > Iroh is named by a certain fictional character that
| likes tea.
|
| "The file was in my sleeve the whole time!"
| tux3 wrote:
| How does this compare to IPFS?
|
| I personally found IPFS very disappointing in practice, so I'm
| very hopeful for a successor.
|
| (The promise of IPFS is great, but it is excruciatingly slow,
| clunky, and buggy. IPFS has a lot of big ideas but suffers from a
| lack of polish that would make Augias look clean. And as soon as
| you scale to larger collections of files, it quickly crumbles
| under its own weight. You can throw more resources at it, but
| past some point it just falls over. It just doesn't work outside
| of small-scale tests.)
| pera wrote:
| https://willowprotocol.org/more/compare/index.html#willow_co...
| rklaehn wrote:
| if you are looking for something similar to ipfs but a bit more
| minimalistic and performance oriented, check out iroh
| https://github.com/n0-computer/iroh .
|
| It is a set of open source libraries for peer to peer
| networking and content-addressed storage. It is written in
| rust, but we have bindings to many languages.
|
| One part of iroh is a work in progress implementation of the
| willow spec. The lower layers include a networking library
| similar to libp2p and a library for content-addressed storage
| and replication based on blake3 verified streaming.
|
| Most iroh developers have been active in the ipfs community for
| many years and have shared similar frustrations... See this
| talk from me in 2019 :-)
|
| https://youtu.be/Qzu0xtCT-R0?t=169
| binary132 wrote:
| Interesting -- does the Rust crate export a C API then?
| rklaehn wrote:
| Not officially. We currently have bindings for rust,
| python, golang and swift.
|
| These were the most asked for bindings (python for ml,
| golang for networking and swift for ios apps).
|
| We are using uniffi https://mozilla.github.io/uniffi-rs/
|
| Would you need C or C++ bindings?
| binary132 wrote:
| Ah, I see. Hm. I might be interested in a C API since
| that could be used in C, C++, and Lua equally well. I
| really was just wondering what the common implementation
| between the bindings was since it struck me as unusual
| that there would be a number of bindings but not C (which
| is AIUI the only interface besides Rust that Rust can
| really export.)
| ramrunner0xff wrote:
| https://veilid.com/ should also be a great alternative. i
| haven't had time to use it yet, but it was built to address
| performance issues with ipfs and allow for both dht style
| content discovery, but also for direct websocket connections
| for streaming (and doing that in an anonymous fashion)
| rklaehn wrote:
| This looks very interesting. They made very similar choices
| than we (iroh) did. Rust, ed keys, blake3.
|
| They seem to do their own streams, while we are adapting
| QUIC to a more p2p approach. Also the holepunching approach
| seems to be different. But I would love to get more
| details.
| ramrunner0xff wrote:
| https://yewtu.be/watch?v=Kb1lKscAMDQ
|
| this was the presentation at DC'31. i will also check out
| iroh! thanks for working in building something in this
| space, it is much much needed!
| rklaehn wrote:
| Thanks. This is awesome. I think they are doing more work
| themselves in terms of crypto, whereas we rely on
| QUIC+TLS more.
|
| Regarding holepunching, our approach is a bit less pure
| p2p, but has quite good success rates. We copy the DERP
| protocol from tailscale.
|
| I am confident that we have a better story regarding
| handling of large blobs. We don't just use blake3, but
| blake3 verified streaming to allow for range requests.
|
| Also I wrote my own rust library for blake3 verified
| streaming that reduces the overhead of the verification
| data. https://crates.io/crates/bao-tree
|
| I tried to get on their discord at
| https://veilid.com/discord, but I get an invalid invite.
| You know a better way to get in touch?
| ramrunner0xff wrote:
| hmm this is strange, i tried the invite and it worked for
| me. If you are on fedi, @thegibson@hackers.town is part
| of the team.
|
| thanks for the links, i will get in touch personally when
| i try ir0h :)
| orthecreedence wrote:
| Hi, I'm super intrigued by Willow and your work on iroh. Do
| you have any kind of documentation on how iroh deviates from
| Willow, or what parts of Willow are planned to be implemented
| vs omitted?
| detourdog wrote:
| Can you quantify the breaking point of IPFS and the number of
| files. I was considering it for a project that has fewer than
| 200,000 entries.
| tux3 wrote:
| It depends on how many files you have, but also the file
| size. My understanding is that IPFS splits files into 256kB
| chunks with a content ID (CID), and then when you expose your
| project, it tries to advertise every CID of every file to
| peers.
|
| 200,000 files could take a while to advertise, but from
| memory it should work, should hang for less than 15 minutes.
| But depending on your hardware, file size, quality of
| connection to your peers, alignment of planets, etc.
|
| If you add one order of magnitude above that, it starts to
| become tricky. Manageable if you shard over several nodes and
| look for workarounds for perf issues. But if you keep growing
| a bit past that point, it can't keep up with publishing every
| small chunk of every file one by one fast enough.
|
| But it's also very possible perf has improved since the last
| time I tried it, so definitely take this with a grain of
| salt, you might want to try installing and running the
| publish command and see what happens.
| foobiekr wrote:
| I'd be very curious what project you have for which IPFS is a
| good solution.
| detourdog wrote:
| I'm not sold on IPFS but the idea of using a file system as
| a top level global index is attractive to me. I find the 2
| best references for human information is global location
| and time. I think an operating system structured around
| those constants could be a winner.
|
| I'm not sold on IPFS and will look at Willow and IROH.
| foobiekr wrote:
| A global hash-based index is literally an undergraduate
| project to do well. You could even ride atop bittorrent
| if you really had to.
| wharvle wrote:
| Being written in Go may have made development of the reference
| client fast (that was the creators' contention when I asked,
| anyway) but killed its growth as a standard. Inability to have
| a portable lib-ipfs that could quickly, easily, and
| _completely_ give almost any language-ecosystem or daemon ipfs
| capabilities is a real drag.
| ComputerGuru wrote:
| Willow solves the biggest problem I have always had with IPFS:
| it's content addressable, which is nice for specific things but
| not generic enough to make the protocol actually practical and
| usable in the real world outside of specific use cases. (Namely
| you can't update resources or even track related updates to
| resources.)
|
| (Mathematically, a name-addressable system is actually a
| superset of content-addressable systems as you can always use
| the hash of the content as the name itself.)
| nayuki wrote:
| > a name-addressable system is actually a superset of
| content-addressable systems as you can always use the hash of
| the content as the name itself
|
| It's a superset in that sense but not a superset in another
| sense.
|
| In a content-addressable system, if I post a link to another
| piece of content by hash, then no one can ever substitute a
| different piece of content. Like, if I reference the hash of
| a news article, no one can edit that article after the fact
| without being detected. This is a super-useful feature of CAS
| that is not a feature of NAS. Other implications:
|
| * I can review a piece of software, deem that it's not
| malware in my opinion, and link to the software by hash. No
| one can substitute a piece of malware without detection.
|
| * Suppose you get a link from a trusted source. Now you can
| download a copy of the underlying content from any untrusted
| source, without a care about authentication or trusted
| identities. This describes BitTorrent.
| rklaehn wrote:
| To be fair, IPFS does offer not just content addressing but
| also a mechanism for mutability with IPNS. You can think of a
| willow namespace (or iroh document) as a key value store of
| IPNS entries.
|
| The problem with IPNS is that the performance is... not
| great... to put it politely, so it is not really an useful
| primitive to build mutability.
|
| You end up building your own thing using gossip, at which
| point you are not really getting a giant benefit anymore.
| unshavedyak wrote:
| Is the performance a critical design flaw or just an
| implementation issue?
| wavemode wrote:
| > Some questions in protocol design have no clear-cut answer.
| Should namespaces be identified via human-readable strings, or
| via the public keys of some digital signature scheme? That
| depends entirely on the use-case. To sidestep such questions, the
| Willow data model is generic over certain choices of parameters.
| You can instantiate Willow to use strings as the identifiers of
| namespaces, or you could have it use 256 bit integers, or urls,
| or iris scans, etc.
|
| > This makes Willow a higher-order protocol: you supply a set of
| specific choices for its parameters, and in return you get a
| concrete protocol that you can then use. If different systems
| instantiate Willow with non-equal parameters, the results will
| not be interoperable, even though both systems use Willow.
|
| Help me out here - isn't the point of a protocol that two
| independently developed systems don't have to agree on how to
| implement the protocol? What value does Willow have if two
| systems that both purport to be "Willow-compatible" aren't
| compatible with each another?
| cobertos wrote:
| By having a more generic protocol on top, it allows the same
| tools to be used for different specific end results. So shared
| libraries and common debugging tools can benefit more use
| cases. You might even make a "higher-order" tool that can work
| with any willow data, at the cost of specific UI affordances
| that can be used when you know more about the underlying data.
|
| This is sort of how ActivityPub is a thing, but it underpins
| multiple, sorta-but-not-really interoperable systems like Lemmy
| and Mastodon.
| smaudet wrote:
| No I think you are right, this isn't a protocol. Its a protocol
| generator...
|
| "higher order" is some nonsense, and would make me shy away
| from using it...
| gray_-_wolf wrote:
| It is unusual term in the area of protocols, but it seems
| understandable it tries to draw a parallel to higher order
| functions. So "some nonsense" might be a bit strong...
| smaudet wrote:
| Protocols are useful, and as such the costs are high to
| using a bad one. Confused verbiage does not instill
| confidence that the authors know what they are doing, or
| that there is real benefit.
|
| So, perhaps it is strong language, but I think it is a
| reasonable reaction.
| black_puppydog wrote:
| Huh? I'd understand your phrase "protocol generator" to be
| the _equivalent_ of "higher order protocol" in the same way
| that a "higher order function" can be seen as a "function
| generator"...
| smaudet wrote:
| The difference would be that a function, order non-
| withstanding, is (a) callable (site). "Higher order",
| merely means one that takes/returns other functions, but
| they are still fundamentally, functions (callable sites).
|
| A protocol has the property that it is implementation
| independent, but that it has a defined interface (i.e. it
| is immediately usable).
|
| This is neither (not a defined interface, implementation
| dependent). If it doesn't share either property with a
| protocol, then you can't claim that it is truly a protocol,
| "higher order" or otherwise.
|
| This confused verbiage is what should be cause for concern
| - note that I can claim a "higher order" protocol with JSON
| or gRPC - its all the basic building blocks for a protocol,
| just both sides need to implement the same stuff!
|
| Except, neither JSON nor gRPC are crazy enough to claim to
| be a "higher order" protocol, which to me puts this in the
| rubbish bin of over-complicated technologies looking for a
| problem, like SOAP, JavaBeans, OSGi - all of these could
| also be claimed to be "higher order" protocols as well.
|
| The term is meaningless, and so I assume, is this project.
| jazzyjackson wrote:
| its wild to me that you would dismiss a project as
| meaningless because you can't immediately understand it
| smaudet wrote:
| Oh I might read their specs: "Willow is a family of
| specifications:" https://willowprotocol.org/specs/index.h
| tml#specifications
|
| This part looks useful.
|
| But is it useful to be a "willow" family of protocols?
| Probably not.
|
| Their claims on the front page are extraordinary.
| Extraordinary claims require extraordinary evidence, and
| heading the page with nonsense is not a good start.
| mplewis wrote:
| Pretty rude to dismiss a project without reading any of
| its documentation.
| binary132 wrote:
| FWIW, HTTP allows subprotocol / backwards-compatible
| negotiation. Perhaps that could be similar to how
| implementations of this might need to cooperate.
| Joker_vD wrote:
| > What value does Willow have if two systems that both purport
| to be "Willow-compatible" aren't compatible with each another?
|
| That you can claim to support Willow, or be Willow-compatible,
| without actually having to interoperate with your competitors.
| See e.g. the usage history of x509 in the nineties.
| rklaehn wrote:
| Think of it like const generics in languages like rust or C++.
|
| You can make two data structures with a const parameter.
|
| If the parameter is not the same, they are not compatible (not
| the same type). The parameter can be tuned according to the
| specific needs of the application.
| layer8 wrote:
| Protocols can have parameters. The protocol will be
| interoperable between parties who choose compatible parameters.
|
| For example, SSH only works if both sides support and can agree
| on the same cryptographic algorithms, which is something that
| SSH is parametrized over.
| wavemode wrote:
| Unless I missed it somewhere, Willow has no specified
| handshake procedure. So there's no standardized way for the
| two sides to come to an agreement on how to communicate.
| (Willow appears to be completely agnostic even of the data
| encoding used to communicate in the first place.)
|
| In that sense it is even more high level and abstract than
| parameterized protocols like SSH.
| layer8 wrote:
| True, it was an example of how "the same protocol" doesn't
| necessarily imply compatibility. The algorithm negotiation
| procedure doesn't guarantee that there will be an
| agreement, so it is somewhat secondary to the argument.
| sph wrote:
| And I think it's a good idea. Take HTTP for example. It is
| much more than its protocol. Freeing it from those details
| means that what is valid today: GET /
| HTTP/1.1 Host: example.com
|
| Could have the same semantics in any format:
| { "method": "GET", "version": "1.1",
| "headers": [{"name": "Host", "value": "example.com"}]
| }
|
| Of course a server accepting the former won't be able to
| communicate with the latter, but that's just an
| implementation detail that Willow does not want to commit
| to at this stage, and does not make it any less complete.
| Just a bit impractical.
| jcul wrote:
| Not all protocols have to have a handshake to negotiate how
| they will communicate. Sometimes you just need to have both
| sides configured the same way. E.g. PTP clocks being in the
| same domain, having the same delay request mechanism etc.
| whizzter wrote:
| I think the idea here is that Willow is meant to handle "higher
| order" issues like encryption and the especially prickly
| sharing encrypted data within a more cooperative environment,
| so that application builders can focus on their more specific
| applications.
|
| Say that I want to implement something Figma-like for designing
| drug-runner operations, Willow seems to be an excellent
| building block (Yes, the example is kinda out-there but it's
| meant to indicate that genericity intended here).
| conradev wrote:
| I wish the web page came out and said what Willow actually
| provides and what is up to the developer.
|
| As far as I can tell, this is primarily a crypographic
| specification, like Noise (http://www.noiseprotocol.org)
| except for a stateful key-value store instead of stateless
| connections
| tenebrisalietum wrote:
| Is IP useless because the other end might not support UDP or
| TCP?
|
| More practically/less absurdly: is SSL useless because side A
| doesn't support the same ciphers as side B.
|
| Perhaps a Willow negotiation protocol would be needed to
| reconcile, but it's a bad idea from a security perspective
| because it enables downgrade attacks.
| smaudet wrote:
| Comparing apples and oranges.
|
| A protocol is allowed to have presumptions, and then provide
| an interface.
|
| Its not allowed to have no interface at all and no
| presumptions (A void).
| throwaway2562 wrote:
| Still confused here. What is the actual, concrete 'as-a-user-I-
| want-to' application for which this is meant to be an ideal fit?
| Sorry if a dumb question.
| bo1024 wrote:
| Yeah, it would have helped me if they walked through what it
| actually means to "use" Willow. Do I install something like
| Dropbox on my computer? Do I write code that calls Willow as a
| library?
| layer8 wrote:
| It's like Dropbox, including sharing, but without a centralized
| service, instead peer-to-peer.
| dirkf wrote:
| So something like https://syncthing.net/ ?
| layer8 wrote:
| Syncthing doesn't have sharing support AFAICS, but yes,
| Willow could be used as the underlying protocol for
| something like Syncthing.
| rklaehn wrote:
| It's more generic than that.
|
| Syncthing is designed specifically for file system sync
| (and does a very good job). Willow could be used for file
| system tasks, but also for storing app data that is
| unrelated to file systems, like a KV store database.
|
| You should be able to write a good syncthing like app using
| the willow protocol, especially if you choose blake3 as the
| hash function.
| jauntywundrkind wrote:
| It should be able to underpin most apps. The sky is the limit.
| Or your imagination is the limit; whichever comes first.
|
| This is a protocol for generic shared information spaces, where
| each person still owns & can manage permissions for their
| pieces of data in the space. It's a general idea that's present
| & implicit in most existing online spaces.
| jbverschoor wrote:
| Same here. no clue what it does.. It could be a
| syncthing/dropbox something. It could be some sharing protocol.
| I dunno
| jhardy54 wrote:
| Aljoscha and gwil are excellent people, I'm excited to see them
| working together. Looks to me like they're solving some of the
| biggest problems with Secure Scuttlebutt.
| cranberryturkey wrote:
| https://reddit.com/r/willowprotocol
| philsnow wrote:
| > Unreviewed Content
|
| > This community has not been reviewed and might contain
| content inappropriate for certain viewers. View in the Reddit
| app to continue.
|
| Wow, what absolute horseshit. The march continues to acquire
| marketing signals at any cost.
| ynniv wrote:
| _Total erasure of data._
|
| This is disappointing. What's been read can never be un-read; to
| say otherwise is deceptive.
| black_puppydog wrote:
| In the same way, once an attacker can exploit some weakness in
| a system, it's game over. Yet defense in depth is a thing and
| makes it much less likely that bad things happen.
|
| In this case, yes, it's impossible to guarantee that some
| malicious peer doesn't ignore my "plea to delete". But combined
| with the fact that my data will only be replicated to/by peers
| I already have a trust relationship with (as opposed to e.g. on
| a blockchain) it provides another layer of protection that a
| system without deletion simply doesn't have. Not perfect, but
| not useless either.
| ynniv wrote:
| Yes, but that's not what "Total erasure of data" means.
|
| The project's goals are hard and noble. It would be better to
| under-promise and over-deliver than to make everyone question
| their claims. Maybe I'm just a grumpy old man at this point,
| but there are already too many _caveat emptors_ in computing.
| They could have said "better" erasure of data.
| wharvle wrote:
| It's a handy feature to have in the protocol if you're
| operating detached networks using it, and can control all
| the clients. If you're using it as internal infrastructure.
| Which, personally, is the only way I've ever been
| interested in using these sorts of things.
|
| You're right that it's nigh-meaningless for a public
| cluster.
| ynniv wrote:
| Ok, but where exactly is that when the FBI is pulling
| Bitcoin private keys out of files accidentally
| synchronized to iCloud Files? These are hard problems.
| wharvle wrote:
| I don't understand your concern. Guaranteed (if you
| control the clients, for ordinary values of "guaranteed",
| not, like, mathematically-rigorous ones) deletion is a
| handy feature if you need to be able to comply with
| regulations, or just want to be sure you're not wasting
| disk space on stuff you intended to delete, without
| having to do extra work.
|
| Attackers are a whole other matter, and their existence
| doesn't make the feature pointless, for the above
| reasons.
| ynniv wrote:
| _deletion is a handy feature if you need to be able to
| comply with regulations_
|
| This is a good point, and "GDPR compliant erasure of
| data" would be a great way to explain it. As a user I can
| guess what that means, and as an engineer it doesn't
| sound like magic.
| detourdog wrote:
| What is the point of noting trying to accomplish hard and
| noble things. I'm sure there are plenty of people willing
| to take shortcuts.
|
| I appreciate people trying to do something hard and noble.
| ynniv wrote:
| Me too! But let's be honest about how things work.
| detourdog wrote:
| I thought I was. I don't think it has much to do with the
| way the world works. I think it might have more to do
| with how one works the world. There are plenty of people
| that don't want to try the impossible but the impossible
| should be explored.
| rklaehn wrote:
| Prefix pruning is a very different approach than
| tombstones. An update will actually remove data, and not
| just mark the data as removed.
|
| Maybe "total erasure of data" is a too strong promise, but
| the fact that you can not force nodes that you don't
| control to unsee things is common knowledge, so in my
| opinion this does not need a qualifier.
| xpe wrote:
| I can appreciate the spirit of the comment. I'm more pedantic
| than is typical -- perhaps even more than is healthy! Even so,
| I don't think the claim is deceptive.
|
| Willow's claim has to do with erasure of the _networked_ data.
| It doesn't claim that copies people make are destroyed. Almost
| everyone understands and expects that if you can view data, you
| usually can somehow make some kind of copy of it. The question
| usually comes down to: how good of a copy?
|
| Perhaps the best way to prevent perfect copying of data is to
| prevent someone from viewing it on a device they control.
| aidenn0 wrote:
| > Almost everyone understands and expects that if you can
| view data, you usually can somehow make some kind of copy of
| it.
|
| This is true for the target audience of the article, but
| certainly not for people in general. It _might_ be true for
| people in their 20s, but I strongly doubt it 's true for any
| other age range.
| orthecreedence wrote:
| I don't really get what your nitpick is here. There is no
| conceivable way in the universe to unshare information that has
| been shared. The idea here is that you can stop _further
| sharing of that information_. I think that 's a fairly
| reasonable and obvious interpretation.
| randall wrote:
| So stoked about this. Lower level than holepunch, and it sounds
| like it has everything I need to get going.
| pmarreck wrote:
| my first question (given that IPFS doesn't seem to do this well)
| is "does it scale?"
|
| Still useful otherwise if not... assuming there's an actual
| client/server for it on mac/linux...
| rklaehn wrote:
| This is a good question. But it is worth noting that not
| everything has to scale globally.
|
| E.g. in iroh-sync (which is an experimental impl of the willow
| protocol) you are not concerned with _global_ scaling. You care
| only about nodes that are in the same document.
|
| So while if you request hash
| QmciUVE1BqKPXMSvTTGwHZo1ywYdZRm9FfBvEJkB6J4USb via ipfs, you
| are trying to _globally_ find anybody that has this hash, which
| is a very difficult task.
|
| If you ask for some content-addressed data in an iroh document,
| you know to only ask nodes that participate in this particular
| document, which makes the task much easier.
|
| Edit: regarding clients, iroh is released for osx, windows and
| linux. Iroh as a library also works on ios. Download
| instructions are here: https://iroh.computer/docs/install
| waterheater wrote:
| Another webpage compares Willow to other protocols like IPFS:
| https://willowprotocol.org/more/compare/index.html#willow_co...
|
| According to them, data on IPFS is immutable, stateless, and
| globally-namespaced, whereas data on Willow is mutable, stateful,
| and conditionally-namespaced. I interpret Willow as an
| authenticated, permissioned, content-based, globally-addressed,
| distributed database system, where an address has the hierarchy
| and expressiveness of a URL.
|
| One particularly nice feature about the documentation: if you
| hover over an underlined word
| (https://willowprotocol.org/specs/data-
| model/index.html#data_...), a pop-up box provides a definition or
| explanation. Importantly, some terms in the pop-up are underlined
| themselves, so you can dig down into the terminology with great
| ease. More projects should implement this functionality.
| Kinrany wrote:
| What's the purpose of subspaces, given that there are namespaces?
|
| What's the purpose of having separators in the keys?
| orthecreedence wrote:
| This is kind of exactly what I've been looking for. I've been
| trying to weave stuff together with libp2p, but this looks very
| promising as a way to handle a lot of the lower-level junk I
| don't care about. While I didn't go in-depth on the docs, I can
| see that this would be able to model a lot of different
| applications right off the bat. Very cool.
| jd3 wrote:
| other commenters have mentioned ipfs, dropbox, syncthing, etc.
| but this most closely resembles http://upspin.io/ with the caveat
| that willow is p2p and upspin uses a centralized key server
|
| https://www.youtube.com/watch?v=ENLWEfi0Tkg
| KomoD wrote:
| > http://upspin.com/
|
| That does not go anywhere.
| jd3 wrote:
| Oops, should be io tld. Fixed!
| KomoD wrote:
| I really like the illustrations
___________________________________________________________________
(page generated 2024-01-17 23:00 UTC)