News for hackers. Stuff that matters.
Re:Event Sourcing (2017) by guywhocodes on Wednesday January 01, 2020 @09:07PM (#21932393)
That is a very interesting approach, however I can imagine that it can be quite a large database of encryption keys.

I'll have to build a small system for this and try it.

Re:Event Sourcing (2017) by imglorp on Wednesday January 01, 2020 @09:40PM (#21932535)
Oh, why? Holding one key for every human on earth would fit in 8 TB plus read-mostly replicas. You'd delete their key if they made GDPR removal request and the keyless, encrypted, immutable entries would be entombed in place.
Re:Event Sourcing (2017) by pookeh on Thursday January 02, 2020 @12:14AM (#21933197)
What do you do when the data involves multiple people?
Re:Event Sourcing (2017) by shrimpx on Thursday January 02, 2020 @03:58AM (#21933896)
It's unclear (regardless of crypto shredding) what the delete policy should be if the data involves multiple people.
Re:Event Sourcing (2017) by randolorian on Thursday January 02, 2020 @10:05AM (#21935872)
Why would it? Typically you would have one stream per user.
Re:Event Sourcing (2017) by tunesmith on Thursday January 02, 2020 @01:42PM (#21938296)
Event: "User A sent Message X to User B". (I think the answer here is again to have PII be in other repositories, and only refer to them by id in the log.)
Re:Event Sourcing (2017) by specialist on Thursday January 02, 2020 @02:17PM (#21938673)
Good question. Create alias proxies?