RE: RE: Core development report #10: full steam on recurrent transfers
You are viewing a single comment's thread from:

RE: Core development report #10: full steam on recurrent transfers

howo(76)
Published in
#hive
Words
269
Reading
2 min
6y

Thanks for always being there !

You're also doing RC pool stuff as well?

Yes ! Not actively working on it right now because I hit a wall and it's quite boring spending hours while making no visible progress so I figured I'd work on something else to get some "fresh air" until I go back to it But it's almost finished.

regarding encryption (pinging theycallmedan@theycallmedan so he gets a notification), we talked about it on the initial dev meeting about patreon use case: I think it's around 20-25 minutes

Tl;dr: it's very challenging to do it layer one, and I don't think all front ends are ment to have the patreon use case enabled anyways, so I think the patreon hive front end should do the encryption in a centralized manner:

  • encrypt using a key that you store on a centralized database
  • push encrypted content to the chain
  • if the registered user has recorded a recurrent payment in the last, say, month and has given the right contribution to see the content, decrypt the post and show it to him in plain text, otherwise show a link to become a subscriber

The downside is if we have multiple front ends competing. Then you have to hop from one to another to see encrypted content. And then we can think of clever layer 2 solutions with a distributed database with the keys in it that's shared among patreon front ends so they all share the same keys.

But I don't think it's worth spending time on it until we actually see multiple front ends and that being a problem.

@howo: Thanks for always | Ecency