A program and application for finding ways to satisfy members' needs at every level, locally and globally.
Support at every level, wherever a member is.
Distributed Support is a proposed program and application for supporting Drayker members across all levels of need. It relates a member's local context to capacities available nearby and across the global system, seeking practical ways to satisfy material, social, educational, computational, community and other needs without reducing the person to one score.
Physical and virtual infrastructure is one branch of that program, not its definition. In that branch, the substrate is meant to draw on idle capacity that already exists and ordinary devices already running Drayker software. Contribution may come through authenticated and supervised nodes or lighter identity-free participation. Other branches must be designed around the member need being addressed and the safeguards it requires.
A distributed system can decentralize its computers while leaving its members alone with needs that only centralized institutions can answer. If support is not designed across local and global scales, participation remains available mainly to people who already have the necessary resources and conditions.
How it works today. Support is fragmented by institution, geography and category; a local lack can remain unsatisfied even when relevant capacity exists elsewhere in the network.
What would change. A member can present a need through a consented local interface; the program can relate it to nearby responses, global capacities, projects, learning, infrastructure and resource mechanisms, while preserving human review and contestability.
Why the rest depends on it. A system for human development is incomplete if people can contribute to it but cannot use it to seek the conditions required to live, learn, work and participate.
Drayker has internal material on Distributed Support that is not yet specified publicly. It describes a wider member-support program as well as infrastructure mechanisms. What counts as a support need, how local and global capacities are matched, which services require qualified providers, and what the system can promise are still open. The first public specification must define the program rather than treating one infrastructure branch as the whole.
Two mechanisms described for the infrastructure branch are worth preserving without generalizing them to every kind of support:
- Redundancy instead of trust. The same work is computed at several independent points and the results compared, so a wrong or dishonest answer is detected rather than believed. A node that returns faults is audited, and can be removed.
- Scarcity-weighted contribution. What you contribute counts for more where it is scarce. The same bandwidth offered where the network is starved is worth more than where it is already plentiful. The incentive follows need, not volume.
The first design must keep member needs, infrastructure contribution, contextual reputation, scarce-capacity priority and resource instruments distinct. Contributing a node may create attributable history and may justify infrastructure-specific compensation if a later lawful scheme explicitly provides it; it does not automatically create income, return, general priority or greater human worth. Support is not a prize for owning hardware, holding Dktrons or accumulating standing.
Nothing described here is implemented. This repository exists so that the first document about it has somewhere to live and someone can argue with it in public.
- A member-support program and application across multiple levels of need
- Local responses connected to capacities available across the global system
- Material, social, educational, computational, community and other support paths
- Consent, access, qualified-provider boundaries, human review and contestability
- Relation to Dk Personal, UID, Dknowledge, PAP, the Academy, Stations and the capacity economy
- Infrastructure support as one branch: physical and virtual nodes, redundancy, scarcity and audit
- Separation between needs, infrastructure contribution, contextual reputation, resource units and scarce-capacity priority
- A deployed support program, application, service network or commitment of resources.
- A welfare, health, housing, employment, emergency or benefits service available today.
- A guarantee that any individual or category of need will be satisfied.
- A deployed payment, reward or compensation scheme for running a node.
- Any automatic tradable claim, income or return derived from contributing capacity.
- A rule that makes basic-needs support depend on node ownership, Academy history or one reputation score.
The program that connects what a member needs to what the system may be able to provide, nearby or across the world.
Dk Personal can help a member express context and needs under their control; UID can preserve continuity without turning identity into eligibility by score. PAP can host the projects and applications that answer needs, the Academy can carry educational paths, and Stations can become local physical and social fronts. The capacity economy and Dktron/value units may carry governed resource decisions. Dk Network and Living Cryptography support the infrastructure branch. Dk may model options and consequences; it does not acquire sovereign authority over members or resources.
These are concrete and unclaimed. Any of them can be opened as an issue and delivered by one person.
- Define a needs taxonomy and the boundaries between ordinary support, qualified professional services and emergencies.
- Model one complete local-to-global support path: consent, request, discovery, human review, delivery, feedback and appeal.
- Design one bounded pilot that can make no promise beyond its actual capacity.
- Specify how support remains separate from DAF points, general reputation, Dktron ownership and hardware contribution.
- Write the infrastructure subprogram: node tiers, redundancy, scarcity, audit and removal.
Read CONTRIBUTING.md
and GOVERNANCE.md in
the organization. In short: open or find an issue, say in the thread that you are taking
it, branch as fn/<issue-number>-<short-name>, and open a pull request against
master. There is no separate review branch.
Participation is voluntary and implies no compensation, employment or future claim.
- This repository, for what Distributed support is and is not.
.drayker/component.yml. The machine-readable contract, validated on every pull request.- drayker.org/project/dsupport/. The same record inside the portal, with the live board.
- drayker.com/project/dsupport/. The case for it, in plain terms.
Part of Drayker · content under CC BY 4.0