Martin Heidegger

There should be no necessity of change in behavior by the recipients - connection-wise. I think adding it at this point in time would be premature. What I think might...

Hinted at by @karissa _(thx!)_: Intents could be very important to visualize the state of backups of a DAT: Right now hypercores do not ask other peers to share all...

Furthermore I came to think that it can be used for protocol optimization: If a peer identifies as `browse` (non-seed) then no `WANT` requests should be sent to this peer,...

I seemed to have overread that section :blush: > For 2018, recommended default full-file hash functions to include are SHA1 (for popularity and interoperability) and blake2b-256 (already used in other...

I can think of only three ways a server can react to input, if neither of this is done: the server doesn't need session data imo. - delay/increase data throughput...

> I don't see this as a strong argument against this DEP, as "servers" can already do or return whatever they want, based on things like "client" IP address, latency,...

> The example use-case for this DEP was for peers to identify themselves in a chat room. I assume this is for the use-case that a user should be shown...

https://github.com/datproject/discussions/issues/80

Referencing: https://github.com/mafintosh/append-tree/issues/16

> Dat/hypercore should work fine over TCP, in addition to uTP (which runs on top of UDP) I honestly forgot that DAT works over tcp. This obviously mutes my theory...