Add Rule sets for Rune creation #257
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nepet
force-pushed
the
202309-rune-restrictions
branch
2 times, most recently
from
9e72e1b
to
dbd75e1
Compare
nepet
force-pushed
the
202306-add-runes
branch
from
3e9e345
to
c7da007
Compare
nepet
force-pushed
the
202306-add-runes
branch
from
c7da007
to
ecf1ddb
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
dcc7280
to
f6b54ff
Compare
|
Main tasks are done. |
nepet
force-pushed
the
202309-rune-restrictions
branch
from
f6b54ff
to
ca8d144
Compare
nepet
force-pushed
the
202310-cleanup-runes
branch
from
5a09bef
to
05b3a59
Compare
nepet
force-pushed
the
202310-cleanup-runes
branch
from
05b3a59
to
b673db0
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
ca8d144
to
3ce25b8
Compare
nepet
force-pushed
the
202310-cleanup-runes
branch
from
1f7113e
to
2a63c9b
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
3ce25b8
to
ac3064b
Compare
nepet
force-pushed
the
202310-cleanup-runes
branch
from
2a63c9b
to
3297d5d
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
ac3064b
to
590a8ce
Compare
nepet
force-pushed
the
202310-cleanup-runes
branch
from
3297d5d
to
fdc819c
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
590a8ce
to
52201f6
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
52201f6
to
963efc2
Compare
cdecker
force-pushed
the
202309-rune-restrictions
branch
from
963efc2
to
1cb04c3
Compare
|
Rebased on top of for merging. |
|
Rebased on top of |
nepet
force-pushed
the
202309-rune-restrictions
branch
from
1cb04c3
to
d78ebdc
Compare
nepet
force-pushed
the
202309-rune-restrictions
branch
from
d78ebdc
to
dccf3aa
Compare
cdecker
force-pushed
the
main-0.2
branch
2 times, most recently
from
737acd9
to
5a5618a
Compare
Randy808
requested review from
cdecker,
Randy808 and
ErikDeSmedt
and removed request for
cdecker and
Randy808
|
I like the idea but it's hard to see the changes introduced in this branch without a rebase |
ErikDeSmedt
reviewed
May 8, 2024
| @@ -55,6 +55,9 @@ def shutdown(self) -> None: | |||
| self.handle.shutdown() | |||
| self.handle = None | |||
|
|
|||
| def create_rune(self, restrictions: List[List[str]], rune: Optional[str] = None) -> str: | |||
There was a problem hiding this comment.
Could you add a doc-string that describes how to add a restriction?
I fail to understand why this should be a List[List[str]] and not a List[str]
nepet
force-pushed
the
202309-rune-restrictions
branch
2 times, most recently
from
47e046c
to
1e296c5
Compare
Randy808
previously approved these changes
May 13, 2024
|
I think this is good to go, but it needs fixing of the tests. |
We need a modular approach to create new runes with additional restrictions from a base rune. For the ease of use we want to provide predefined rule sets that hold the recipes for the corresponding restrictions, e.g a 'readonly' rule that produces a restriction that only allows for reading operations. - Added a `RuneFactory` that centralizes utilities to carve (create) runes using entities that implement the `Restricter` trait. It comes with a `carve` method that appends restrictions from `Restricter`s to a base rune. - Added a `DefRules` enum that provides predefined rule sets and holds recipes how to generate the corresponding restrictions. `DefRules` implements the `Restricter` trait. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
It seems handy to be able to print the rule set at least for debugging purposes. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We introduce a Context struct that holds data relevant to a signing request and that we want to check against a rune. The struct currently checks the following informations: -method: the rpc method -pubkey: the pubkey that was used to sign the request -time: the timestamp that was part of the rune. (this way we COULD create a rune per command that times out after a certain time) Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We create a context now and check the context agains the rune. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
nepet
force-pushed
the
202309-rune-restrictions
branch
from
1e296c5
to
19fe4f0
Compare
The channels array returned by the rpc call `listpeers` is optional and has been deprecated with v23.02 and will be removed after v24.02 Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
nepet
force-pushed
the
202309-rune-restrictions
branch
from
556e593
to
db2d511
Compare
Replace list_peers().channel (which is optional) with list_peer_channels(). Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Randy808
approved these changes
May 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to provide a system that makes it easy and secure to construct runes with certain restrictions. We provide rule sets for common restrictions and combinations of those.
Example from a user perspective:
A user wants to create and hand out a rune to a bookkeeping application (we all have to do taxes eventually):
The application should not be allowed to move funds, neither off-chain nor on-chain but shall be able to read information from the node. A coarse rule set that is easy to understand (or at least human readable) and fulfills the task would be a readonly set that can be used to construct a rune that restricts the owner to read methods.
Example from an application perspective (pairing-protocol)
A Podcast application uses greenlight without a distinct singer. The application wants to be authorized for a direct debit of max 1000 sat per week
During the pairing-process the application would request a rune that is restricted to pay max amt sat per delta_time via the rule rate(amt, delta_time) that the user can then confirm or reject.
Tasks:
Rules (incomplete, loose ideas):
We do not have to implement every rule from the beginning but I am starting with a hand full of rule sets and recipes to ensure that our approach is modular enough.