in: https://cryptpad.fr/pad/#/2/pad/edit/0KOvdwf7L+1d6sYKYjtRtpf5/

Good overview — you already have a clear grasp of the pain points. Here is what is concretely needed for each point to go from local/PoC to public:

1. Public relay + WSS

Your relay must run on a public IP, with a domain + TLS certificate (Let's Encrypt). Nginx or Caddy as a reverse proxy for the WSS tunnel ( wss://relay.yourdomain.nl ). For browser↔browser you also need a TURN server (e.g. coturn ) because browsers cannot traverse NAT on their own. Without TURN you fall back to relay-only, which does not scale.

I’ll just call this problem: scalability. What you want is to verify the history of the person’s personal ledger/blockchain, together with their history. At the moment we still do everything with simple database actions. We are constantly adding information to the database. Only in the users table are there fields that change (as far as I remember). I think that in the end we will also do that (stuff everything into one database) with 8 billion people (if they even all exist). That will become a big database. But in the end this does not need to happen in real time. If you make a transaction, you are offered the entire history/ledger of the other person and you also give yours to that person. At a later stage you can “offer” the transaction to the “database” to validate and store it. However, this is all a future concern and actually seems relatively simple to solve to me. I can’t follow the paragraph above. I don’t understand that stuff.

2. Online hosting / IPNS

Two options:

Keep your own node online — a VPS with go- ipfs / kubo running 24/7 and serving pinned content. IPNS works as long as the node is online.

Remote pinning — Pinata or web3.storage pin your content; they guarantee availability. IPNS via DNSLink is then more stable than native IPNS (you publish the CID as a _ dnslink TXT record → no more TTL problem).

DNSLink is probably the easiest production solution for IPNS stability.
Once we have it running a bit, we will probably go with Remote Pinning. I’m happy to take that on.

3. Write permissions (ACL)

The pubkey claim already exists — you only need to enforce it. Every write operation to OrbitDB / GunDB must be validated server-side (or relay-side): is the signature over the payload valid for the claimed pubkey , and does that pubkey have write access to that store? This is one verification step but it requires the relay not to be trustless — or you use OrbitDB's built-in access controller ( AccessController with write: [ pubkey ] per store, not '*' ).
Above my pay grade. Seems like a database matter to me. Security is not very important in our system because everyone can see the perpetrator.

4. Identity binding

You need a challenge-response on first login: the server sends a nonce, the client signs it with its private key, and you verify it. Only then do you link the userId to that pubkey in your backend. Without this, anyone can claim any userId . This is one API endpoint + a signing library on the client side (e.g. libsodium or ethers.js if you already have a wallet flow).
See 3

5. Community key

A shared secret from env is fine for a PoC but not for production. Options:

Asymmetric : community key pair, private key only on the server, clients encrypt with the public key.

Rotation : send a version number with each message, keep old keys temporarily valid during the transition.

For now the main thing is: do not keep the key in the repo, but in a secrets manager (e.g. Doppler, Vault, or simply GitHub Secrets if you use CI/CD).

See 3. What is important is the hash of the most reliable version of the 1CoinH program. How do we arrange that?

6. Double-spend resolution

Detecting is step 1, resolving is step 2. As long as the Qortal anchor is not there yet, you can implement a simple "last-write-wins with timestamp" or "first-confirmed-wins" policy as a temporary measure — explicitly documented as interim. Important: communicate this to users (UI notification in case of conflict).
Double spending is not an issue for us. We only need a control program (which I call "Sentinel") for duplicate identities based on cross-checks. This will matter later and for that we need some smart programmers/mathematicians.

7. Email notifications

Relatively separate from the rest. SendGrid or Mailgun has a free tier; you can integrate it via a simple serverless function or your relay backend. The static site in English is a separate choice — do you want multilingual support or English as the baseline?
As far as I’m concerned, email is one of the bells and whistles. Not strictly necessary . We can always solve that later.

Order for production

If I had to prioritize:

Relay on VPS with WSS + TLS (blocks everything)

DNSLink + remote pinning (availability)

Enforce ACL on write operations (security)

Identity-binding challenge -response

Community key rotation

Double- spend policy

Notifications

https://cryptpad.fr/pad/#/2/pad/edit/0KOvdwf7L+1d6sYKYjtRtpf5/

for locale focus of atention

There is a clear opportunity to leave the broken paradigm LAPMP and the way we work and share.

this is just a quick mind dump

for the 100th time a new salient synthesi inspired by the occasion and talking with You'all

I'll expand this with personaly archived annotated and inded innotated pages soon

I mentioned Charls simony, as my Friend from "litle england Hathersage" (The Shire, Hobit land, Middle Earth in tolkien's parlance) another "bloody" Hungarian
His way of thinking he characterised by saying "Anything You Can do I can do Meta)
In fact his PhD theis was something like the "Meta Programmer" designing systems of high complexity minimum complications and directing an group of programmers, not programming with 10 finger's but 100 or more.
that is a characteristic Gambit with Hungarians, some of whose eyes lit up when somone claims that something is impossible. They ar drawn to make the impossible inevitable

Somony looiked a tthe way we build systems

with a functional spec and a non-funmctional spec

Where the functional spec would say what he system is intended to accomplish
the non functional consider the the infrastructure constellationand the required scale both in term of data and communicaion and latency requirements
His vision was to decouple the two. That is to say deal with the conceptual/intentional structure of the system functional requirements)

and formulate them in a way that enebale mutlipe inrastructure constellations to be created once and combine the tow
This is in contrast with current practice, where the non functional requirements get's us to chose appropriate mechanism to deal with storage, communication connetcivity etc all driven by required levels of scaling and in effect uild the functions using those chosen infrastructural component. so the cost is not a sum of some functions of the number of intentional concepts in the functional requirements plus he infrastructural concepts
but effectively the product of those two

the one salient feature of what yee (y'all) the mesing forgotteh third person plural in English, intend to do and what I am after is inter personal connectivity, not a centralized system, not just decentRalised but interpersonal interplay,

not a platform but an interplayform

The task is not simply to deliver some capability but do so so that it can interplay with other

Commons based Peer produced Open, not just in source but Open sauce capabilities that are constructed and constellated so that they work on the individual's own machines, browsers, local-first, even of-line first, born interplayeable with other such capabilities across the Web.

forming interPersonal networks of Human actors and autnomous, autopoietic capabilities, where people can do it for themselves, tinker extend, comnine in novesl ways existing capabilities. like to call this as the IndyWeb

Cryptpad is good for online work, and communication.

We can miror all this in say Peergos, which can be run on your own machines, so it would work offline too.
Combine that with sharing information in a granual manner, so that information is shared and flows through async interpersonal trust networks, one that cannot be hrvested by crawlers. Even if all the bits and pieces are out there in the IPFS network, the networks of connections that make them whole itself is only visible through trusted connections and parties

and each such exchange of information is made availabe along side verifiable permanent provenance information

referring back to the point about exchanging ledgers

If you make a transaction, you are offered the entire history/ledger of the other person and you also give yours to that person.

each party in the exchange will make available a minimal adjacent connected network Dots, nodes pertinent portion of their own networked information, extract of their own 'networked wiki' pages, that are deeply intertwingled via bi-directional intentional/meaningfully transparent links, that are relevant to the dynamic scope of the exchange , and do that mutually in an ventually consistent manner

Each participant maintains their own time bound dingle thread of threads. Nobody else writes into their own local view of the network, no concurrentcy, it is all flows with time. with full historical/version history whih itslf is recapitualbel.

Another imposiblility rendered inevitable.

No conflicts possible and version control is integral and routed through the participants with replayeable flows

Instead of creating systems with seeking optimal choices, al they achieve is lock you solution into eventually limiting choices,

adpot an omni optional stance, and create the conditions that is able to integrate any possible choices.

Workflows are designed so that they can interplay with any web based system.

the focus is on always on the ability obtain an HTML document from other systems, which is what the Web IS.

In the worst case, it is always possible to personally archive any web page, and bring that into 1's own indranet work space

This universal approach also means that 1 can create 1's own Personal Web Archive, so the information that 1 engages with is permanently preserved in a private copy,
This enables 1 to experience, the web as an extension of their mind, with permanence.

Clearly the latency requirements of interpersonal communicaion and transactions radiclaly different from a centralized povider based system,

where each participant is a firt class netizen of the system,

with local storage and autonomy, etc

combine that with IPFS and one universal interpersonal connectivity component and scaling no longer requires choosing any other infrastxture
In fact consideration sof scaling should be part of the a uniersal yet fully extensible pattern of working.
powers of 12's as a basis each will bring ever higher levels of aggreagtion ut using the same underlying mechanism at scales

Remeber the old saying: when the computers get connected in network, the network becomes the computer

When people are empowered to explore, organiz the Net's frontier, share their work autnonomously, connecti with each other conversse and colaborate that are continuous without being synchronous, on their own terms, own their own contributions, for the benefit of the participants, intearact , interplay with others and the entire web, when services come to them instead of they going to places where they are provided, that interplanetary permanent evergreen network becomes the externalization of their shared inter intellect through mutual learning (Symmathesy)

Abundonomy~ToDo