Show thread history
Joe Ruelle
2mo ago
Is this a more serious risk if clients with traction stop writing events to outside (as opposed to reading events from outside)? I see that on the read side this introduces risks like seeing content that is out of date, or in the worst case purposefully altered.
Or is it that the read side alone comes with its own potential implications?
Or is it that the read side alone comes with its own potential implications?
See translation
1
0
0
0
0
Replies
daniele
@dtonon
2mo ago
> or in the worst case purposefully altered
Fortunately this is not possible, events are signed.
But a blocked/delayed sync could effectively be a dark tactic from a client that has a large userbase.
Fortunately this is not possible, events are signed.
But a blocked/delayed sync could effectively be a dark tactic from a client that has a large userbase.
See translation
0
0
0
0
0
Joe Ruelle
@JoeRuelle
2mo ago
Ah yes, I was thinking more along the lines of counts and such that a client can only achieve with some kind of central-server model, and that users would therefore be trusting the client on (seeing as they can't get such accurate counts from the protocol itself.) But I didn't think about blocked/delayed sync for notes themselves as a dark tactic, that's an interesting thought.
Where I'm a little confused still is why this cacheing sometimes seen as a looming threat to the model when it's just on the read side? I'd totally get it if it was on the write side too, but if just on the read side then it seems to be benign enough, like watching live events streamed on YouTube but things being buffered a few minutes for smoothness.
Where I'm a little confused still is why this cacheing sometimes seen as a looming threat to the model when it's just on the read side? I'd totally get it if it was on the write side too, but if just on the read side then it seems to be benign enough, like watching live events streamed on YouTube but things being buffered a few minutes for smoothness.
See translation
0
0
0
0
0
daniele
@dtonon
2mo ago
Users always have to trust clients, they don't have the other way.
For reactions/zap/replies at protocol level, we are evaluating HyperLogLog (see https://github.com/nostr-protocol/nips/pull/1561) that seems to be a good (probably the only) solutions to an aggregate counting in a decentralized structure. There are risks about gaming the system, but they can be attenuated; therefore, they are already present today with a plain sum of events done by clients.
The reading cache is not only a cache, is potentially a totally new API abstracted on that data, probably with more processing (e.g. extracting images/videos data, text metrics, etc). This off-protocol approach gets from the network, but doesn't give back nothing, and so it creates an unfair competition since casual users that don't know these technical details see these off-protocol clients as a better choice, ignoring that they cannot exist without the protocol devs that hardly work every day
For reactions/zap/replies at protocol level, we are evaluating HyperLogLog (see https://github.com/nostr-protocol/nips/pull/1561) that seems to be a good (probably the only) solutions to an aggregate counting in a decentralized structure. There are risks about gaming the system, but they can be attenuated; therefore, they are already present today with a plain sum of events done by clients.
The reading cache is not only a cache, is potentially a totally new API abstracted on that data, probably with more processing (e.g. extracting images/videos data, text metrics, etc). This off-protocol approach gets from the network, but doesn't give back nothing, and so it creates an unfair competition since casual users that don't know these technical details see these off-protocol clients as a better choice, ignoring that they cannot exist without the protocol devs that hardly work every day
... See more
See translation
0
0
0
0
0
Joe Ruelle
@JoeRuelle
2mo ago
Very enlightening, thanks!
See translation
0
0
0
0
0