Drayker General Forum — threads

Write the triage protocol for a single veto

2026-09-25T05:46:55Z

What is delivered

A written triage protocol for a single veto whose grounds bring information beyond the scope considered before the decision.

Cover at least: how the facts claimed are verified (records, sensors, independent sources, people and local Dks of the context); how the meaning of the new information for this decision is established, not only its truth; how error, misunderstanding and manipulation are detected, including coordinated vetoes with copied grounds; how the smallest adjustment is chosen (exception, bounded test) before any general change; time limits so that verification does not make the veto useless; how the anonymity of whoever vetoed is protected when the grounds could identify them; and how a contested triage reaches the independent member panel. Include one worked case.

Why it is needed

A single well-founded veto can change a decision. That is what makes the veto intelligent, and it is also what makes it an attack surface. The safeguards exist in prose across UID, Dk and the governance; nothing yet says step by step how a triage is carried out and recorded.

Where to start

The veto chain in UID, the council and panel description in this repository, and the constitutional alignment paper in Dknowledge.

This is an open function: small enough for one person to finish, defined enough that the result composes with the rest. Claim it in this thread before starting so two people do not carry the same function, and deliver through a pull request to master. It appears on the board at https://drayker.org/#org/fn

Carry one veto through a network partition

2026-09-25T05:46:53Z

What is delivered

A small, reproducible experiment that carries one veto through a network partition, with the code or scripts and a short report.

The sequence: a veto is signed on a disconnected device; the network splits in two; the device reconnects to one side; the entry propagates and is checked by at least three independent nodes; the partition heals; an execution layer that was about to carry out the contested action refuses it once the entry arrives. Report what happened to ordering, duplicates and conflicting histories, and how long each step took.

Why it is needed

The veto chain is only as strong as its behaviour under failure. "Replicated and accepted by propagation" is a claim until someone shows what a real partition does to it.

Where to start

The section "Carrying the veto chain" in this repository's README and the veto chain in UID. Any small simulation or container setup is fine; the point is a result someone else can rerun.

Specify one entry of the veto chain

2026-09-25T05:46:51Z

What is delivered

A specification of one entry in the veto chain: its fields, what is signed, what is public and what is sealed.

Cover at least: the address of the contested decision; the grounds (intention, motives, scope, facts) and which parts can be sealed so that only triage reads them; how the entry proves that its signer is a member with standing in the affected context without revealing who they are; the hash of the previous entry; and the signature. Close with three worked entries in sequence: a veto, the triage outcome that answers it, and a panel order.

Why it is needed

The veto chain is described in prose in this repository, and several others point to it: Dk, Dk Personal, Dk Network, the councils and the Drayker governance. Until an entry has a concrete shape, none of them can be designed against it, and the promise that a veto cannot be lost, forged or quietly ignored cannot be checked.

Where to start

The section "The veto chain" in this repository's README. Existing append-only logs, certificate-transparency logs and anonymous-credential schemes are good prior art; say what each would get wrong here.

Bring the Português README up to date

2026-08-11T22:59:37Z

What is delivered

README.PT.md carrying the same content as the English README.md, including the sections added when the specification was published.

Why it is needed

The Portuguese README is four paragraphs describing how a unit joins and how resources work. The English one now also says what the federation is for, where the specification lives, what the record in federation/ holds, and — importantly — what is and is not running.

That last part is what makes this more than tidiness: a reader arriving in Portuguese currently gets no warning that nothing is operational yet. The gap between the two files is the gap between an invitation and an honest one.

Where to start

README.md is the source. Keep the link to the English version at the top and the note about which one is ahead.

Terms that should not be invented fresh — federative points, function, module, unit, assembly — appear across dafp/. Consistency with those matters more than elegance, because the same words carry the mechanics.

Translating DAF-000 and DAF-001 is a much larger job and is not part of this function. If you want it, open a separate one.

Design the ICP migration for Phase 1, against the conditions that would force it

2026-08-11T22:59:35Z

What is delivered

A proposal in dafp/ for moving the federation onto ICP: what it would run, what it costs, what it carries across, and which condition triggers the move.

Why it is needed

ICP is the stated direction — the reason being reputation and resource management that a repository cannot carry. DAF-001 §7 records that direction and deliberately separates it from the trigger: naming where the work goes is not the same as deciding when it goes there.

That separation is the whole point of this function. Three previous attempts picked a platform first — Aragon on Ethereum, then DAOhaus on Optimism, then canisters on ICP — and each was abandoned before deployment. The reason was never the design. It was that a deployment demands funding, tokenomics and an audience before the federation has recorded a single decision. The direction was right more than once; the order was wrong every time.

Where to start

DAF-001 §6 is the requirements list, already written: no censorship resistance, no cryptographic guarantee, no sybil resistance beyond judgment, no anonymity, no custody. A useful proposal says which of those ICP actually fixes, and at what running cost per year.

Three things worth being concrete about:

Migration of the record. The history in federation/ has to survive the move with its attributions intact. A design that starts everyone at zero throws away the only thing Phase 0 produces.
Anonymity. The hardest of the conditions and the least explored — the earlier drafts describe contributors who cannot participate publicly, and no phase has an answer for them. Treating it seriously is worth more than a fast recommendation.
What stays out. The transferable instrument is out of scope by DAF-000 §6.1. A substrate that can hold one does not by itself settle whether it should.

An answer that is only a platform comparison repeats the mistake this function exists to avoid.

Status, 2026-10-09. Part of the ground this function covers now exists, so a proposal can start from it instead of from zero:

icp/, added in #24, is a Motoko reading of the event log of DAF-002 §6. It reproduces every event hash and the standing of every holder, byte for byte, and includes a canister that would hold the log and certify its head. Nothing is deployed. Its README lists what would move and what would not, the toolchain limits, cost notes and the open questions.
Migration of the record, above, is therefore partly answered: the history can be replayed and verified outside the repository's own tools.

Still open, and the part this function asks for:

which condition of DAF-001 §7 would trigger the move;
what running it would cost per year;
how anonymity would work;
which phase may use ICP (GOVERNANCE §1 and DAF-001 read differently).

Run the first assembly, against work that already happened

2026-08-11T22:58:47Z

What is delivered

One completed assembly cycle in federation/assemblies/, run end to end against a delivery that has already happened — not a hypothetical one.

Open the cycle as an issue, claim the delivery, draft the report from the template, hold the seven-day window, record the tally, merge. The procedure is DAF-001 §4.

The specification of the DAF federation itself is a candidate: it was declared in a public issue, its result is inspectable, and it closed.

Why it is needed

The rules are written and nothing has ever been run through them. Quorum at 30% of active points, one point per function, a bonus per function on module completion — these are starting values that no use has validated. The first assembly is the cheapest possible way to find out which of them are wrong, and it costs nothing but the time to hold it.

Running it against real work also settles the awkward first question honestly: the founding steward holds a majority by construction, because the steward did the work. Better to have that visible in a real ledger than described in a document.

Where to start

DAF-000 §3.1 for what counts as delivered, DAF-001 §4 for the cycle, and the three templates in federation/.

Expect the templates to be wrong somewhere. The last section of the assembly report exists for exactly that — write down what the rules cost to operate, so the next revision argues with evidence.

Status, 2026-10-09. This function cannot be completed yet. Weight in a vote comes from the assemblies held before it, and before the first there are none, so the first assembly is a founding assembly. DAF-000 and DAF-001 do not say how a founding assembly is decided. Until DAF-001 §4 does, the tally reports its outcome as undetermined, close does not write it, and check stops on a report that records it (federation/README.md, "Running an assembly", DAF-002 §7).

The procedure has also changed since this issue was written. Cycles and claims use the issue forms, and the report is drafted, counted and closed with node tools/daf.js draft, the Federation tally workflow and node tools/daf.js close, as described in that README section.

Specify an experimental ledger of contributions and accountability

2026-08-11T10:46:37Z

What is delivered

A specification for an experimental ledger: contributions, needs, decisions and accountability. Who takes part, what the unit of record is, who reviews it, and what ends the experiment.

An accounting exercise. Deliberately.

Why it is needed

The order of work here is the thing most likely to be got wrong. The first validation is an accounting one, not a monetary one — a transparent record of what was contributed, what was needed and what was decided, before anything moves and before any unit exists to move.

Nothing internally demonstrates monetary policy, liquidity, audit or financial governance, and this component does not promise income, return or support payments to anyone. A ledger is what makes the rest possible to argue about honestly.

Where to start

"Unit of record" does not mean currency. Hours, deliveries, commitments met — the question is what can be recorded consistently enough that two people reading the ledger agree on what happened.

Whatever this becomes, it stays inside the limits on the economy page: no token, no exchange, no return.

Prior material

Drayker has earlier work on this subject in its own knowledge base — drafts, mostly in Portuguese, written before the public repositories took their current shape. It is not published yet. If you take this function, say so in the thread and the relevant material will be published alongside it, so you are consolidating and arguing with existing thinking rather than starting from a blank page.

Build one pilot learning experience

2026-08-11T10:46:34Z

What is delivered

One pilot learning experience built around a single problem, with one observable delivery at the end and one human review of it.

The problem, the material someone would work through, what they hand in, and what the reviewer looks for.

Why it is needed

The Academy is not a gate — it is not a requirement for taking part, and it certifies nobody. That makes it harder to design, not easier: it has to earn its place by being useful to someone who could have skipped it.

One experience that actually works is worth more than a curriculum nobody has run.

Where to start

Pick a problem that already exists as an open function somewhere in this organization. Formation attached to real work is the whole premise, and there is no shortage of real work.

Prior material

Design one pilot activity, with no place required

2026-08-11T10:46:10Z

What is delivered

A design for one pilot activity — local or remote, no place required: who coordinates it, what support it offers, how participation is measured, and the condition under which it ends.

Small enough that one person could run it, specific enough that someone could say it failed.

Why it is needed

This component starts with an activity, not with a building. A physical centre is only considered after there is evidence of demand and of something that can sustain itself, and right now there is no instrument that would produce that evidence.

There is no inventory of properties, no staff, no budget, no licences and no confirmed pilot. This function is what turns a long-term idea into something testable this month.

Where to start

The ending condition is the part people skip. A pilot that cannot fail teaches nothing, so decide up front what result would mean "do not do this again".

Prior material

Write what a support node is, in both tiers

2026-08-11T10:46:06Z

What is delivered

The first description of what a support node is, in both tiers: the authenticated, supervised node the main network relies on, and the light contribution the secondary network accepts without identity.

For each: what it contributes, what it has to guarantee, what it is trusted with, and what happens when it returns a wrong result.

Why it is needed

The design already says trust here comes from redundancy rather than from reputation — the same work computed at several independent points and compared. But nothing public says what a point is, which makes the guarantee unfalsifiable.

Without this, "decentralized" is a claim about intentions.

Where to start

The two tiers are the interesting part. Something contributed without any identity still has to be worth trusting under comparison, and saying exactly why is most of the work.

Prior material

Demonstrate evidence organization on one non-clinical question

2026-08-11T10:45:44Z

What is delivered

One non-clinical research question, and a demonstration that does only this: search, explain, or organize existing evidence about it. On synthetic data, reviewed by someone with domain expertise.

Written up so a reader can see what was done, what the limits were, and where it would break.

Why it is needed

This repository describes a domain where overreach is not a style problem — it is a safety problem. There is no clinical protocol, no validation, no dataset, no device, no regulatory approval and no safety evidence, and the honest first step is deliberately unglamorous.

Doing the small version well is what earns the right to describe anything larger.

Where to start

Non-clinical means the output cannot be read as being about a particular person's health. Organizing published findings on a research question qualifies; anything resembling a diagnosis, a recommendation or a triage does not.

The specialist review is part of the deliverable, not a formality after it.

Prior material

Write one concrete personal use case

2026-08-11T10:45:41Z

What is delivered

One concrete personal use case, written out: who it is for, what actually hurts for them today, which data the agent would be allowed to touch, what result it produces, and how you would judge whether it worked.

One person, one situation. Not a feature list.

Why it is needed

Dk Personal is the thinnest component in the ecosystem, and unlike the others there is no unpublished specification waiting to be released — internally it exists as an index note and an admitted interpretation. Nothing about what the agent may keep, send upward or refuse can be settled while the thing it is supposed to do stays abstract.

This function is first on purpose. Everything else in this repository waits on it.

Where to start

Pick a situation you actually recognise. An assistant designed from a persona tends to produce guarantees nobody needed.

The one constraint that is not negotiable: no real personal data, anywhere in the example.

Describe the minimum project lifecycle, without an economy

2026-08-11T10:45:17Z

What is delivered

A description of the minimum project lifecycle, with no economy of its own attached: create a project, set an objective, invite a participant, review a proposal, record a contribution, and close or reuse the project.

Six steps, each one saying what has to exist for it to happen and what is left behind when it does. No funding, no reputation, no distribution — those depend on components that are themselves unspecified, and pulling them in here is what keeps this from being written.

Why it is needed

Projects & Applications is meant to be where every other project in the ecosystem lives, which makes it the piece most likely to be designed by accumulation. A lifecycle small enough to describe in one document is what makes the rest arguable.

Where to start

The hardest step is the last one. Deciding what happens to a project that ends — discarded, archived, or turned into something another project can clone — shapes everything before it.

Prior material

Write the first-time contributor guide

2026-08-06T03:14:19Z

What is delivered

A guide for someone who has just decided to contribute and does not know the system: where the map is, how a function is claimed, how pull requests to master are checked and discussed, and what happens after they open their first pull request.

Why it is needed

The portal explains that you do not need to know the whole system to contribute to it. It does not yet explain the first twenty minutes.

Where to start

The DFM page and the open-functions board describe the shape of the work. This function is the missing bridge between "I want to help" and the first claimed function.

Where it lives is part of the function — this repository, or dknowledge alongside CONTRIBUTING.md.

Decide whether OSDK is active architecture

2026-08-06T03:14:17Z

What is delivered

A short document, and an update to this repository's README, stating whether OSDK is an active part of the Drayker architecture or an early idea kept for the record — with the reasoning.

Why it is needed

OSDK has a published documentation site and a one-sentence description, and it does not appear in the ecosystem map at https://drayker.org/#org/eco — so a reader cannot tell whether it is a live layer or a fossil. Either answer is fine. Ambiguity is not.

Where to start

Compare what OSDK claims to do with what Dk Network and UID already cover. If it overlaps entirely, say so.

Expand the ethical code of Dk

2026-08-06T03:14:15Z

What is delivered

docs/ethos.md written out, beyond the single sentence it currently holds.

Why it is needed

The documentation itself says the ethical code is one of the most important parts of Dk's intelligence. What is published is one line. A statement of importance without content is the weakest kind of claim a system can make about itself.

Where to start

The manifesto and the principles at https://drayker.org/#org/manifesto are the values the rest of the system already commits to. This function is about what they mean for an intelligence that acts.

Prior material

Date-audit the papers and the roadmap

2026-08-06T03:14:13Z

What is delivered

A list of where the published papers and the roadmap no longer match the current state of the projects, with dates.

Why it is needed

This is the most complete documentation in the ecosystem and also the oldest. Parts of it predate the current shape of the projects. A reader today cannot tell which parts are still current, and that quietly undermines everything else here.

Where to start

Read papers/ and roadmap/ against the current repositories and the ecosystem map at https://drayker.org/#org/eco

You do not have to fix what you find. Listing it accurately is the function.

Write the identity requirements

2026-08-06T03:14:11Z

What is delivered

A requirements document for UID: what a unique identity in this ecosystem must guarantee, and what it must never do.

Cover at least: what an identity is bound to; how a participant proves control of one; whether identities can be separated or held pseudonymously; how contribution history attaches to an identity; and what happens when an identity is lost.

Why it is needed

UID is described as the primary system design and the basis for every application on the platform. No requirements are published, so nothing about it can be designed against or argued with from outside.

For a system whose premise is that strangers cooperate, how identity works is not a detail to postpone.

Where to start

Prior art and objections are as welcome here as proposals. What existing identity systems get wrong is a good place to begin.

Prior material

Publish a worked example of a project proposal model

2026-08-06T03:14:09Z

What is delivered

One complete example of a project proposed through DFM: the issue modelled, fragmented into functions, with the modules that connect them made explicit.

Why it is needed

The repository describes the idea of distributed, modularized projects but does not publish the models it refers to. Proposing a project is therefore harder than it should be — the only way to learn the shape is to guess it.

Where to start

A real proposal works better than an invented one. Any of the open functions in this organization could be written up as the example.

Prior material

Publish the first motion for resolution on the base structure

2026-08-06T03:14:06Z

What is delivered

One motion for resolution, published in docs/, on a concrete part of the base structure — how a function is described, how modules compose, or how the structure is meant to evolve without discarding what works.

Why it is needed

This repository is described as the place where motions for resolution on the kernel's base structure live. None are published. One worked example would show what a motion looks like here and unblock everyone who would write the second. Drayker holds earlier architectural work on the base structure that has never been published — consolidating it into a motion is a legitimate way to do this.

Where to start

The ground rule is published and binding: only the requirements of Dk and the Drayker platform are final. A motion argues for a solution to those requirements; it does not redefine them.

Prior material

Write the research charter for Meta DFM

2026-08-06T03:14:04Z

What is delivered

A document stating what Meta DFM actually covers: the mathematical and logical protocols underneath DFM, and how the engineering swarm — the teams and artificial agents working on the technical architecture — is meant to be coordinated. Include which problems get modelled, against which requirements, with what method, and how a result is judged good enough to change an architecture decision.

Why it is needed

BSDK, Dk and Dk Network all defer their final shape to "optimal solutions proposed and developed with metaprogramming intelligent algorithms and research organized through DFMP". They are pointing here. This repository publishes one line of intent.

Until this is published, three other repositories are deferring to work nobody outside can see.

Where to start

None of this requires a model to run. It requires the unglamorous part to be written: the questions, the criteria, and what would count as an answer.

Prior material

Write how a council works

2026-08-06T03:14:01Z

What is delivered

A first version of "how a council works": how a council is formed, how someone joins one, which councils exist or should exist, how a council records a position, and what weight that position carries in DFMP.

Why it is needed

DFMP says validation runs alongside development and that papers pass through the DAOs and/or councils depending on their purpose. Nothing about the councils themselves is published. For a system whose legitimacy rests on decentralized peer review, that is a load-bearing absence.

Where to start

The DFMP README and dfmpp/README.md describe where councils appear in the process. This function fills in what happens inside them.

You do not need authority to write this — propose it, and let the communities argue it through.

Prior material

Specify federative points and the voting procedure

2026-08-06T03:14:00Z

What is delivered

A specification of how federative points are earned, held and counted, and how a decision of the federation is actually taken.

Cover at least: what counts as delivered work; who confirms it; whether points decay; how points map to voting weight; what can be voted on; quorum; and how a resource request is evaluated against the rule that support is a last resort.

Why it is needed

The README states that DAOs accumulate federative points and voting power over federation resources and decisions. None of the mechanism behind that sentence is published — neither the contract, nor the point mechanics, nor the voting procedure.

For a federation whose whole premise is cooperation without an owner, this is the gap that matters most. Drayker has substantial unpublished work on its economic and resource model; this function is largely about consolidating it into something reviewable.

Where to start

The published rules are the constraints: the initial DAO is funded by grants and side projects; support requests only where there is no alternative; resource efficiency matters; main projects are the priority. Any design has to keep those true.

Prior material

Write a threat model for re-encryption on failed authentication

2026-08-06T03:13:58Z

What is delivered

A threat model for the design where a failed authentication changes the cryptographic scheme: what it defends against, what it does not, and what it costs.

Why it is needed

The claim is strong — that repeating a brute-force attempt stops paying off, and that the system gets stronger under attack. A claim that strong needs an adversary written down next to it.

Where to start

Useful attacks to reason about: an adversary who fails deliberately to force re-encryption; the cost of re-encryption to legitimate holders of the data; what happens to data in flight during a scheme change; and whether an attacker can distinguish schemes.

A well-argued "this does not hold under X" is as valuable as a defence of the design.

Prior material

Specify the uPOW: inputs, cost and verification

2026-08-06T03:13:56Z

What is delivered

A specification of the unit of proof-of-work a requester must run: what it takes as input, how its cost is set, how the distributed system verifies it, and how the split between authentication work and network work is decided.

Why it is needed

The uPOW is the mechanism the whole security model rests on, and what is published is currently one paragraph of prose. Nothing about it can be reviewed, implemented or attacked on paper in its present form.

Where to start

The README describes the intent. The hard questions are the useful ones: who chooses the difficulty, what stops it from being a denial-of-service against legitimate users, and what exactly the network gets back for the work spent.

Prior material

Recover or rewrite the Initial Network Architecture

2026-08-06T03:13:54Z

What is delivered

The Initial Network Architecture, published in this repository — or, if it cannot be consolidated from existing material, a first version written against the requirements that are published.

Why it is needed

The README lists the network requirements and then says "Other requirements are specified in the Initial Network Architecture". That document is not published anywhere public, so the most consequential document of this layer is currently a reference to itself.

Where to start

The published requirements are the contract: two networks, the layers of the main network, compatibility with Living Cryptography, modular and evolutionary protocol, intelligent interconnection, separation of layers and subnetworks, distribution and fault tolerance, offline adaptability, DFM architecture. A rewrite has to satisfy them, not replace them.

Recovering and consolidating what already exists is worth more than rewriting from scratch.

Prior material

Bring the Spanish protocol README up to date

2026-08-06T03:13:52Z

What is delivered

README.ES.md matching the current English README.md.

Why it is needed

The English README was rewritten and the Spanish one is now behind it.

Where to start

Compare README.md and README.ES.md.

Bring the Portuguese protocol README up to date

2026-08-06T03:13:50Z

What is delivered

README.PT.md matching the current English README.md.

Why it is needed

The English README was rewritten and the Portuguese one is now behind it. A translation that silently lags is worse than no translation, because a reader has no way to tell.

Where to start

Compare README.md and README.PT.md. The existing Portuguese text is real translation work — keep its voice where the content still matches.

Write DFMP-000, the proposal process paper

2026-08-06T03:13:47Z

What is delivered

dfmpp/dfmp-000-dfmp-proposal-process.md written out: the path a proposal takes from an idea to a legitimated paper on master, in enough detail that someone who has never proposed anything here can follow it without asking.

Cover at least: what a proposal must contain before it is presented; how it is presented to the community through the issues; what "widely discussed and validated" means in practice; which DAOs or councils see it and how that is decided by purpose; how it enters the approval folder; how the pull request targets master and passes automated checks and public discussion; and how an update to an already-legitimated paper is handled.

Why it is needed

The file exists and contains only its own title. Every other repository in the ecosystem defers to "research organized through DFMP" — the process they defer to is currently undocumented.

Where to start

The README of this repository and dfmpp/README.md already describe the shape of the process in a few sentences. That is the skeleton; this function is the body.