Possible to generate a one time secret which all nodes on the distributed network can know but cannot pre compute I have a distributed P2P network.

Everyday, I want each node to have a secret which is only valid for that day, while each of the other remaining nodes on the network will be able to calculate the same value.

However, I do not want any node to be able to precompute this; for example, if it is Monday I do not want any other node to be able to compute the secret until Thursday evening / Friday

Is this possible? What kind of scheme would be needed for this to be effective?

Edit - have to edit here as i do not have enough reputation to comment, thanks for the answers so far, it would be impossible for me to have a centralized server, as this would break my model, can we achieve this without the need of centralized servers, and as for my adversary model, currently i am assuming a network of 5,000 nodes, which anything up to 49% of computing power maybe comprised by an attacker, so a solution needs to take into account the computer power at the disposal of an attacker and cannot relay on it might take x days

Edit 2 - The network is not closed, and yes the secret would need to be known to all 5,000 + nodes, but only be able to be computed / distrubted on a specfic day and valid for that day, i have been looking at network voting systems, all nodes compute a hash based on the previous days hash (like the bitcoin hash challenge where the solution is a nonce when added to another hash has x amount of zeros first) and then the average or mean of these is the secret used for the next 24 hours
If you have the bandwidth to do so, and good communication reliability between the nodes, you can perform a multi-party Diffie Hellman key exchange. The most efficient way to do so would be using X25519, resulting in a shared 256-bit secret between all parties. This can then be used to derive keys and other secret values.

This would also allow new nodes to be added to the network at any time, their public key would be added to the pool and all parties would calculate a new shared secret from the current secret. Parties would have to agree on the time it takes to distribute and calculate the secret, and use that to agree on a set time when that secret would go into effect. If it takes approx 5 mins to distribute all the public keys, they may start communicating to the network 7 mins in advance so there will not be a blackout period where some nodes do not have the secret calculated.

Bandwidth can be reduced substantially if a node trusts other nodes to forward a public key to other nodes on their behalf, and computation can be reduced if a node trusts other nodes to compute an intermediate shared secret from the rest of the network.

A ring-bus design could also be used, where nodes transmit to a single peer, and they receive from a single peer, and transmit the pool they receive which grows by 1 with each transmission. At the end all nodes should have the same list, and they can verify a hash of the key pool with other nodes randomly. If a peer does not have the same hash, but does have all keys, they may have been given an intentionally incorrect key(s), and procedures can be put in place which allow groups of peers to determine where the incorrect key(s) originated (traitor tracing).

The most reliable option is to have a node send its public key to all peers in the network, and receive the keys from all other nodes as well, resulting in $n^2-n$ total key transmissions for $n$ peers, then validate the list with several other peers.

Another option is available if all nodes have a permanent shared secret, the network is open, and nodes can access the internet without restriction. A high entropy public value, such as the output of the NIST randomness beacon, can be processed with HMAC, using the permanent secret as the key. The resulting output would not be able to be generated in advance of the beacon, and will be cryptographically secure because of the generation method, as long as the secret remains isolated to the network.

A combination method can also be used, in advance of the beacon publication, all nodes use Diffie Hellman to agree on a shared key for processing the next days beacon, this gives plenty of time to verify that each node has the same key. This would be the best option for nodes on an open network with a wide range of distribution (high latency), or a very large number of total nodes.