Eric explains his position. Clean audit. That's the norm. Shows presented financials. Comparing audited numbers with FinComm/AC. Chief take-away, the audit committee needs to have a perspective on these financials. Because adjustments. Tobie: I understand your point about bad debt, there are two things. One is accounting practice and the other is a management problem. We need to give

Some components of the IPFS stack, notably CIDs and IPLD, are either not being adopted because of their complexity or when they are adopted are being stringently subsetted. This points to there being value in aligning on a common subset so that disparate projects can reuse shared code, can interoperate where meaningful, and so that we can build a wider shared understanding around the foundational bricks of self-certifying protocols. DASL Overview DASL is a lean, practical, interoperable subset of IPFS. It is

The WAG is a small gathering of projects working on secure and private web app formats and environments to collaborate, find common ground, and learn about each other's work. where: Europe, possibly Brussels or Amsterdam. when: 2024 Q4 (aiming for October), probably over two days who: (not the final list by any means, most of these people haven't been asked)Peergos WebXDC Delta Chat Cheogram Monocles

Informational 100 Continue 101 Switching Protocols 102 Processing 103 Early Hints Success 200 OK 201 Created 202 Accepted

In order for IPFS to be successful not just with people who are already committed to a decentralization agenda but in a wider community that might simply want to try something and see if it can do useful work, there is a number of very basic user stories that need to work flawlessly and to be easy to find in the documentation. These basically involve people in common development exploration contexts attempting very simple operations: serve, get, verify, and maybe sync. On my command line I am reasonably proficient with a command line and wish to interact with IPFS using simple command line tools that are sufficiently similar to other commands in that environment. Serve I have a directory of content (that may have subdirectories) and I want it to be available on IPFS. The HTTP equivalent is: http-server .. There are other options that are just as simple, http-server is widely available (from npm, from brew, runnable with npx if it isn't installed, etc.). When you kill it, it stops serving the content.

This document captures how the Board manages issues and action items. A point of terminology: Issues are intended to capture a problem or topic that the Board neesd to spend some time addressing (though not necessarily immediately). Action items are specific actions that people (typically one person) are expected to carry out. Issues Everyone is empowered to create a new issue at any time. Unless there is a good

Today's generation of promising projects, often around decentralized systems, need to be ecosystemic from the get-go. We are dealing less with individual endeavors that grow and more with complex projects that require a diversity of stakeholders early and that may cross institutional boundaries. Experience shows that this is hard to pull off: Projects that start from a product-centric approach (build it, then create standards for other implementations to join), will invariably create centralization chokepoints around a single company and struggle to increase community ownership. Absent more formal governance the project is effectively led by a self-selected group that may have good intentions but isn't really accountable to the community. Centralized hacks deployed in a hurry and supposed to be removed later tend to be sticky. They are even stickier when they are bankrolled by the company that started the project: the community has no reason to start paying, the company needs to keep maintaining them for the broader project to succeed, and as a result the overall system is cosplay decentralization. Open source or open standards projects aren't set up to make money. They typically operate on a more or less functional honour code in which some of the major beneficiaries of the infrastructure will have a way to monetize the work and "donate" some time to maintenance. What if open projects could make (fiat) money, which they could then recycle into paying the people who work on the project? Infrastructure for shared specifications that make multiple independent implementations possible (formats, change management, maturity level, test suites…) is harder to put together than most realize and there is previous little available off-the-shelf. Existing standards organizations are poorly suited for this kind of work, often too bureaucratic, hostile to decentralized projects, or not adapted to this kind of close integration between specification and product work.

IPFS is too closely tied to Protocol Labs; this is a proposal for an independent entity to serve as its steward. We expect the entity to evolve over time and to ramp up the degree to which it is community-led. This document focuses on the initial stage during which it will exist under provisional governance in order to establish it on solid ground. Questions (Strike these off as they get addressed.) Phase 0 — IPFS Ecosystem WGWhat is IPFS in Outercore that this group does not do now? What is the message when we announce on Aug 24? themes: ipfs focus, ecosystem Phase 1 — Nucleated IPFS Foundation/Coop

User agents act as intermediaries between a service and the end user; rather than downloading an executable program from a service that has arbitrary access into the users' system, the user agent only allows limited access to display content and run code in a sandboxed environment. End users are diverse and the ability of a few user agents to represent individual interests properly is imperfect, but this arrangement is an improvement over the alternative — the need to trust a website completely with all information on your system to browse it.RFC 8890: The Internet is for End Users, Mark Nottingham Trust has been the defining constraint on the web's evolution towards more powerful, more

This is not (yet) a governance proposal for IPFS; at this stage it is a set of notes and questions about how IPFS governance could work. The idea is to discuss and iterate, and to let some of these ideas marinate in the community for some time. Basic Governance Structure A plausible and pragmatic governance structure could look roughly like this: NomCom. A nomination committee is composed of all the people who have contributed to the community over the calendar year that precedes any action of the NomCom (typically an election). What counts as "contributing to the community" is something that should be

This draft specification proposes a format for Web Tiles. Informally, it can be thought of as the wild love child of Web Application Manifest and Content Claims Protocol. Essentially, manifests provide useful metadata for a bundle of content and content claims make it much easier to provide content that already exists on HTTP in an IPFS-friendly way (ie. using CIDs that can be further supported by verifiable claims). Note that:

Governance and community are two ideas that vibe like they wouldn't live in the same part of town if their lives dependended on it. Community is warm, fun, and fuzzy if probably chaotic and occasionally infuriating, whereas governance sounds a lot more like flossing, something dry and painful that you pretend your project does to make the Serious People go away. But much like the predictable transition from misunderstanding to mutual respect in a buddy movie, these two were destined to form just the dynamic duo we need to take on insuperable odds. Community is the for and by of governance, and, quite frankly, the exercize of governance is messy, chaotic, and a crucible from which new, more resilient communities emerge.

:::danger READ THIS FIRST — OR ELSE! Work on this document has been moved into a PR to the specs site. Comment there if you have feedback! What remains here is only the previous discussion. NO CHANGE BELOW THIS LINE WILL BE TAKEN INTO ACCOUNT. NO CHANGE ABOVE IT EITHER, MIND YOU.

:::success TODO [ ] re publishing on the top-level specs site: could the site be repurposed so as to only contain the minimal viable specifications set? does that mean that it would import that multi* specs so as to be essentially complete? ::: CAPER is a minimalist iteration over IPFS, focused on providing a bedrock interoperability layer for typed content-addressed data in a way that is efficient, well-defined, and reasonably easy to implement.

As currently specified, the did:web method hardcodes a .json extension for DID document retrieval, be it from the .well-known default or for specific users. It simultaneously expects that document to be a JSON-LD document (see step 3 under Create). At the same time, the DID Implementation Guide has a whole multipage section cautioning against the risks involved in mixing up JSON and JSON-LD, and not using the prescribed media types being application/did+json and application/did+ld+json. This is cause for some consternation. If there is one thing that the past 30 years of standards have taught us, it's that, particularly in a heavily distributed context with many actors and no central enforcement, you get a lot more interoperability by creating standards that match how people use technology rather than trying to shoehorn people into some narrow pet peeve about correctness. There's a lot more of them than there are of you, and implementers care more about making their users happy than standard wonks. The truth of the matter is that the vast majority of did:web documents are, because their URLs end in .json, going to be served as application/json. In fact it's very likely that DID documents in general (at least those that use a JSON syntax), being produced and served using JSON tools, are going to end up serving their documents as application/json no matter what. And the second that this is common, processors will just accept it.

As Mark Nottingham wrote in RFC 8890: The Internet is for End Users: [O]ne of the most successful Internet applications is the Web, which uses the HTTP application protocol. One of HTTP's key implementation roles is that of the web browser -- called the "user agent" in [RFC7230] and other specifications. User agents act as intermediaries between a service and the end user; rather than downloading an executable program from a service that has arbitrary access into the users' system, the user agent only allows limited access to display content and run code in a sandboxed environment. End users are diverse and the ability of a few user agents to represent individual interests properly is imperfect, but this arrangement is an improvement over the alternative -- the need to trust a website completely with all information on your system to browse it. All The Fails It is a beautiful vision, but unfortunately it is more aspirational than real. It fails in different ways: For the longest time, privacy was not (properly) considered to be part of the threat model and violating privacy was not seen as a violation of trust that a user agent should protect against. This is wrong: the risks from privacy are real, privacy is deeply connected to trust, and UAs do need to protect privacy.

ipseity: The quality of being oneself. This document seeks to improve our standards posture across everything. I'm stealing some thoughts from @lidel and expanding on them. Right now, we have standards scattered somewhat all over: https://github.com/ipfs/specs https://github.com/libp2p/specs/ https://ipld.io/specs/ https://github.com/multiformats/cid