WNFS v2 Munch & Learn

A #munch-and-learn about what @matheus23 learned from working on the WNFS “v2” prototype implementation in typescript, including some thoughts on how a WASM WNFS implementation could look like.
Mainly aimed at engineers, but also not going super in-depth on the actual algorithms, encodings nor data structures.



Permalink: https://ipfs.runfission.com/ipfs/bafybeiekcefunonczqp462pze3f755kjihgxn6ml5e4kv3anxh4r2m2ucq?filename=WNFSv2MunchAndLearnSlides.pdf

Chat Log
00:21:37	Brendan O'Brien:	This is replacing bloom filters from recent WNFS spec?
00:21:44	Brooklyn Zelenka (@expede):	This is the bloom filter
00:21:51	quinn:	As I understand it, they're implemented with bloom filters
00:21:56	Brooklyn Zelenka (@expede):	They are
00:21:59	Brooklyn Zelenka (@expede):	😛
00:22:18	Brendan O'Brien:	🙂 lovely, ty
00:22:47	Brooklyn Zelenka (@expede):	There’s several ways of doing accumulators, we’ve chosen a method that has short witnesses to fit into a UCAN
00:26:16	quinn:	Double checking - is the revision the hash out of the current skip ratchet iteration?
00:26:21	Brooklyn Zelenka (@expede):	It is
00:26:25	quinn:	Thanks!
00:26:33	Brooklyn Zelenka (@expede):	👍
00:26:41	Brooklyn Zelenka (@expede):	Good questions in the chat!
00:28:43	Brendan O'Brien:	Skip > Spiral. Nice change 🙂
00:29:42	Brooklyn Zelenka (@expede):	Yeah it looks a LOT like a slip list underneath. Ironically this was the original name, but went with the more geometric metaphor. Writing that paper really solidified that skip is a better term
00:34:51	Brian:	Maybe thin clients?
00:35:14	Brooklyn Zelenka (@expede):	Overloaded I think (thin client / heavy server)
00:35:24	Brendan O'Brien:	Or maybe blockchains don’t get to own the term “light client” 😛?
00:35:28	Brooklyn Zelenka (@expede):	THIS
00:35:45	Brooklyn Zelenka (@expede):	We’ll call them Lite Clients, just to confuse everyone
00:35:54	Brendan O'Brien:	loight
00:35:55	quinn:	Litening Clients
00:36:01	Brooklyn Zelenka (@expede):	Amaze
00:36:14	James Walker:	Lyght Clients
00:36:24	quinn:	Is "resource constrained device", as in from IOT, a decent analogy?
00:36:33	Brooklyn Zelenka (@expede):	Yup!
00:36:38	Brooklyn Zelenka (@expede):	Or low end smartphone
00:36:46	Brooklyn Zelenka (@expede):	(Or heck, high end smartphone)
00:38:58	Brendan O'Brien:	Ooops yeah the go implementation codes around this, & doesn’t create new versions on `mkdir -p` type calls
00:39:30	Brooklyn Zelenka (@expede):	👍
00:53:12	Boris Mann:	Light InterPlanetary Services (LIPS Client)
00:53:26	Brendan O'Brien:	Zomg a lip service
00:53:31	Brooklyn Zelenka (@expede):	OMG
00:53:52	Boris Mann:	And of course pet names have to be worked in, in some way
00:54:15	Brendan O'Brien:	Get a pet, name it lips. Problem solved?
01:02:08	Brendan O'Brien:	If you’re including network calls in your Blockstore, folks in IPFS land refer to this as a BlockService
01:04:57	Boris Mann:	Network should be abstracted
01:05:07	Boris Mann:	Eg. WNFS in WASM over WebRTC / Matrix
01:05:07	quinn:	Is blockstore based on or like a free monad?
01:05:30	Brooklyn Zelenka (@expede):	@Quinn expand on the idea?
01:05:50	quinn:	Being able to impose different interpreters over the abstract block operations and then execute them at the end
01:05:54	quinn:	compose*
01:05:58	Brooklyn Zelenka (@expede):	@boris agreed — we should be able to create a blockservice out of a blockstore + networking
01:06:09	Brendan O'Brien:	Yes, that’s how it works in go land
01:06:11	Brooklyn Zelenka (@expede):	@Quinn I think the idea is more like a multilevel cache
01:06:20	quinn:	👍
01:11:46	quinn:	That was really great!
01:11:48	Brendan O'Brien:	THANK YOU