(Adapted from Vasco's original proposal) Introduction The Bad Bits Denylist is a public list of hashed Content Identifiers (CIDs) that have been flagged for various reasons, such as copyright violations, malware, and other forms of abuse. This list helps IPFS node operators —such as public IPFS gateway providers—choose to opt out of serving content flagged as problematic by other authorities or services. IPIP-383 took the first step on decentralizing content moderation in IPFS setups. However, the only list being published in this IPIP-383 format is the output of the current takedown process centralized under Protocol Labs, requiring manual review via email or Google Form submissions. This process lacks transparency, is prone to inefficiencies, and does not scale with the growing needs of the IPFS ecosystem. Currently, error messages (on any gateway) refer the requester of a taken-down CID to this central process, so while multi-list functionality is already live, no other lists are available on denyli.st or in IPFS documentation/tutorials. Waiting for organic demand is not enough to spread the responsibility and service burden to non-PL-operated gateways. Facilitating the development of multiple lists and weening people off of status quo (total dependence on a single list) require some incentivization and investment in the community.

Top-Level issues Capabilities can be scoped to:universal (wallet-scope) --> chainId 0x0 in EIPs chain-scope batch-scope call-scope dapp/wallet dynamic which scopes can a dapp request, for each capability can wallet reply at a different scope?

Possible use-cases for discussion (throw any ideas here) Alice wants to publicly post where she wants to get paid (e.g. alice.eth@optimism is in her twitter bio) User Stories Alice got an airdrop on Bob-Chain and wants to sell it for Dai on Optimism, where she is saving up. She puts those tokens in escrow and publishes a sell order payable for XX Dai sent to alice@optimism (exact format tbd) Polymarket use-case (targeted, human-error-proof deposits)FA4BDBF9-8D68-4FAB-9CC6-95377D27F22D https://x.com/VitalikButerin/status/1810633473750683974 Goals A.) Hard Requirements

hackmd-github-sync-badge DIF Interoperability WG Note: For entertainment purposes only, all claims self-attested and not based on interop testing or conformance suites! This was crowd-sourced and unconfirmed anecdotal research for educational/exploratory purposes, and never edited as a deliverable of the working group. --juan caballero, 10/2022 Note: Similar effort is now ongoing under the OpenWallet Foundation. See Digital Wallet and Agent overview We (the DIF Interop WG and guests) are trying to get a ballpark notion of which types of credentials each "wallet" can HOLD (be issued) and PRESENT (use to generate VPs). Nits:

Meeting 25/09/23 delay issue kyle: examples ?boidu: zerion extension handles 1193 in a sep script anyways, and that's what most people are copypasteingbut that's not linked from docs or anything, people are getting that from the tg chat daniel: rainbow had this issue too, but caught it with our error handling logic kyle: spec is currently recommending freezing window.ethereum and other objects as a SHOULD, but that can have unpredictable effects for other dapps/other contexts kyle: brave when implementing was thinking about which objects need to be frozen (Event, providerDetails, provider, etc), but that's not nec the spec's fault; barring a plugathon / test suite additions, we will have to wait for users to open issues to bugtrap further

README: https://github.com/LedgerDomain/did-webplus Why not did:web? lack of built-in 'historicity': One of the biggest challenges in delivering did:web within a highly regulated industry such as the pharma supply chain is its lack of built-in "historicity." Many real-world did:web implementations assume that W3C Verifiable Presentations are ephemeral, needing to be verified at time of receipt (e.g. to access a particular resource) but not requiring retroactive verifiability in the event of a later audit.

Attendancebumblefudge James (https://jamesg.blog) Tantek Çelik (https://tantek.com/) Ben Savage (Meta) Evan Prodromou David Somers (https://omz13.com) Bob Wyman Manton Reece (https://manton.org) Angelo Gladding (https://ragt.ag)

Demo of wallet test framework intro: Sam and Nicky (sp?) have been working on it for a few weeksfront-end PRs welcome! functional for now https://wallet-test-framework.herokuapp.com "manual glue" for now-- enter chainID etc (cut and paste from pre-configured metamask, for ex.) running against a serverside ganache (for RPC definitions) could be built from npm package wtf.allwallet.dev Browser Interfaces

hackmd-github-sync-badge How to use this document: Please give it a quick skim-through to get the hang of the format and function before editing feel free to add pointers, links, open questions, in amongst the othersbig chunks of text and screengrabs (can be CTRL-V'd straight into hackmd btw) should go at the end of sections, below open questions eventually, as sections get unwieldy or too detailed for this structure, we'll move them out into their own documents hackmd comments are kind of unwieldy, but feel free to @ people in new comments indented below the ones you're asking about

If you're reading this, you're probably trying to get "fancy" with your "Connect Wallet" flow in one way or another. Here are a few use-cases supported by our powerful, but dauntingly flexible new dapp-wallet negotiation: Dapp wants to check for support of a chain-specific method (skip ahead to see the code snippets) Dapp wants to know, with as few clicks and user-interactions as possible, which exact signing methods a wallet supports (skip ahead) Dapp wants to take advantage of L2-specific functions, without awkward failure modes if the wallet can't or the user won't approve it to (skip ahead to see the code snippets) Dashboard dapp wants to know which kinds of blockchain to query, by which chains the wallet supports. (skip ahead) But first, let's look at how CAIP-25 messages are structured: The Basics: Syntax and Semantics

Over the last 9 months, an important and productive outgrowth of prototyping and design conversations in Verite has been the On-Chain Best Practices Working Group, which has met weekly to compare notes on VC implementations, identity token implementations, and all the mechanics of registries and records intended for on-chain consumption. What follows is an overview of a few heuristics that we've landed on as independent criteria for assessing and designing end-to-end system connecting realworld identities to on-chain pseudonyms. Think of them as orthogonal axes, which might be more or less important in a given situation or use-case. We do not believe all of them can be perfectly "solved for"; if anything, identity is a realm of trade-offs, where scoring high marks on one axis usually requires cutting corners on another. Axis X: Granularity of Data Points Too many conversations about on-chain identity take a binary view of "personally identifiable information", in which any given piece information either "personal" or "opaque", i.e., not-personal. That isn't how adtech and industrialized digital surveillance works today, so it shouldn't be how we conceptualize the privacy threat model; all static data, particularly "strong" data, is a "data point" and any strong linkage between datasets in different contexts builds a graph expanding out to every other data point linked to those data points... For that reason, we have discussed onchain markers as additive, i.e., adding an [immutable] data point to all the others which would be included in an NSA, chainalysis, or adtech profile about a person if its linkage to the rest of the profile were probabilistically/inferentially linked. In this way, what matters is not the binary personal/impersonal, but how useful it would be to a probabilistic linking mechanism, which is what matters in privacy modeling. This is often called "coarseness" of information, i.e., saying as little as possible, and differentiating a pseudonym as little as possible from the millions of others in a system. Swirlds Labs

hackmd-github-sync-badge Editors: Juan Caballero (Centre.io) Martin Riedel (identity.com) Egidio Casati (NymLab.it) Robert Mao (ArcBlock.io) Fabrice Rochette (2060.io) Andrea Scorza (LTOnetwork.com) Raphael Roullet (Violet.co)

Year in Review A year ago today, I started full-time working on Verite, coordinating research on my fronts and moving from prototype and "cookbook for an ecosystem" to production trials, compliance research, and use-case exploration. It's been a great year and we have a lot to be proud of-- but also a backlog of updates to the documentation, as the exploration has yielded iteration and variation, new frontiers and new constellations of design. This post will serve as a milestone report overviewing those discoveries, new research directions, and ongoing conversations. Compliant Membership For all of this year, we remained laser-focused on one use-case: "membership proofs" that attest to a specific blockchain address being a member of a coarsely-defined "compliant pool" that has been checked to a minimal level, which reveal minimal identifiable data on-chain or on the open web. Delivering this value is what Verite was created to do, and all other use-cases we have been working on follow from it and build on it -- or, to put it another way, are unlikely to go to production until our primary use-case has users and traction, as "follow-on" products and "knock-on" network effects. Our research uncovered much complexity and diversity among the on-chain consumers of these membership proofs, which leads us to support different variations and form-factors for this use case and the supporting technical work needed to go beyond mere membership. We found: Some smart-contract-based consumers only wanted to consume membership proofs on-chain, making a strict "nothing on-chain" approach across all Verite architectures unworkable Other smart-contract-based consumers want to outsource the enforcement of a compliance policy (usually roughly defined, and expected to be refined over time) to a single service, with an expectations of real-time monitoring and complete separation of concerns.

Who's on first PartiesJonathan Holt (TranSendX) Victor Dods (LedgerDomain) Juan Caballero (PLN/LearningProof) IP? Confidentiality? Meeting minutes

PRs to refine/move to close namespaces#34 - You are the best, SERGEY! (already merged) namespaces preview thru gatsby that sergey shared on discord? juan will attempt GitPages version mimicking Frederick's next week and if he fails tap Sergey to install gatsby juan will attempt replaces: ["[CAIP-3](github.com/91263981263981263/3/)", "CAIP-21", "CAIP-22"] backlinks - if jekyll lets him? rocco transferred over *.chainagnostic.org --> gitpages in DNS settings

PRs to refine/move to close n/a Ongoing projects/topics Brief Discussion for context: History of recently deprecated MM Enc/Dec API based on EIP-1098 (further receipts: [EIP magicians thread] | github PR history | 2019 rust crate | gitcoin grant ) Brief discussion as possible input doc/starting point for a CAIP: the new EIP hoping to supercede 1098, 5630 (further receipts: EIP magicians thread | github PR history ) Juan highly recommends everyone read Kyle and Authors' exchange in the Magicians thread above

NOTE: DO NOT SHARE THIS LINK-- anyone who gets this link can read it, hackmd doesn't have an authZ model like gdocs does! References MM f WC CAIP-25 - current open PR

Abstracts Joe Andreiu: did:merkle abstract: https://hackmd.io/vU8fyUcQQe662arw9OOPZg Mirko Millik: credential profile comparison: https://hackmd.io/ikhimdHLRy247YgRhNIXmw Lal (iGrant) https://hackmd.io/@lalchandran/HkFnRtgzs

PRs to refine/move to close CAIPs#130 - CACAO example syntax ship it! Ongoing projects/topics Should all the following be #channels on Discord to funnel/catch more activity? Or DISCUSSIONS on github? Should one-off calls be announced there?

link to this file: https://hackmd.io/ g w v F 0(zero) l(ell) b 4 T 8 S n H G m g w H z B J g Schedule Time Session 11:15am Opening Session - What is CASA and how you can help