08

8 - Authorizing other peers 🐴 🐹 🐰

Until now, all that we've seen has involved local tests with our database but we have not interacted much with the rest of our computers.

It's time to change that.

Back to hyperdb & hypercore

Remember that we are using hypercore and on top of that, hyperdb. Let's make a quick pass over both, until know we know that

• Dat is singlewriter, for now.
• hypercore is the 💗 of Dat.
• hypercore allows us to create a feed (data structure) where we can write/read and share.
• Each feed gives us a public key that can serve to identify it (and us).
• A feed can be seen like an append-only log.
• hyperdb is a db that operates over a group of feeds (hypercores).
• hyperdb allows DAt to support multiwriter

How can we let other peers write on our feed?

It works in the following way: an writing operation in the original author's feed (the creator of our chat, in our case), indicates the peer that wants to write. The form to identify the peer is through their public key (PK), to say, this peer 🐴 could pass their PK of their way.

Internally, hyperdb writes in the feed, as if it was another message (but a special message) which determines a peer 🐴 can write.

Exercise

1. Saga should support a new method (API) which permits it to authorize a peer. This method _authorize receives a parameter PK.
2. This new method returns a promise that when it resolves successfully, delives a string AUTHORIZED, and when it rejects, it passes the error through.

Tips

We will use two methods from hyperdb API:

• authorize, is used to authorize another peer.
• authorized, is used to check if some key was already authorized.

Test

$ npm test ./08

test.js

Solution

solution.js