Dedicated Endpoint for Permit Generation

[0x4007]

Now that we have a prototype of delegated compute¹ to move towards a paid API infrastructure we should make a dedicated endpoint that has secure access control.

Definitions

• Partner Repository Partners - this is where the work is being done.
• Permit Endpoint Permits - this is our paid endpoint, which is being prototyped on GitHub Actions now.

Version I

A specialized version of the API that will be used specifically for our current use-case, which is calculating comment incentives, and assignee rewards.

Permits Input

This may be simpler to implement, as it will be specifically for the comment incentives. Permits will fetch the repository comments from the GitHub API using the gitHubPersonalAccessToken.

const postBody = {
	evmPrivateKeyEncrypted: "xxx", // this can serve as an "API key" as they are associated with partners in our database.
	gitHubPersonalAccessToken: "gh_pat_0123", // with repository read permissions, especially for rate limiting and private repos
	eventName: "issues.closed",
	issueOwner: "ubiquity",
	issueRepository: "ubiquity-dollar",
	issueNumber: 128,
};

Permits Output

We can just send the entire comment body with the permits as HTML.

Fee Collection

• The simplest method is to generate an extra permit for us. We can charge 1% in Ubiquity Dollars or 5% in WXDAI, and we can automatically claim it from within the script.
• If the transaction is successful, we can post back the results. If the transaction is not successful, then we can throw an error.

Version II

Permits Input

We can generalize this API for any GitHub event, and any GitHub repository. This would allow us to have a single endpoint for all of our partners, and we can use the eventName to determine the rewards structure.

const postBody = {
	evmPrivateKeyEncrypted: "xxx" // this can serve as an "API key" as they are associated with partners in our database.
	rewards: [{
        gitHubUserId: 4975670,
        amount: "10000000000000000000", // $100,
        asset: "0x2260fac5e5542a773aa44fbcfedf7c193bc2c599", // i.e. WXDAI,
    }];
}

Permits Output

type TransmitPermit = {
	amount: string; // 1e18
	beneficiary_id: number;
	// created?: string;
	deadline: string;
	// id?: number;
	// location_id?: number | null;
	nonce: string;
	// partner_id?: number | null;
	signature: string;
	token_id: number;
	// transaction?: string | null;
	// updated?: string | null;
};
type TransmitPermits = TransmitPermit[];

Footnotes

1. essentially delegating a serverless function to another async runtime that supports longer running operations, and then returning results via a webhook ↩

[0x4007]

Turns out we don't need PATs at all if the bot is installed on both repositories. Will update this specification to reflect this later.

Source.

As a heads up @wannacfuture @whilefoo

[ubiquibot]

! action returned an unexpected value

[ubiquibot]

! action returned an unexpected value

[ubiquibot]

! action returned an unexpected value

[wannacfuture]

Turns out we don't need PATs at all if the bot is installed on both repositories. Will update this specification to reflect this later.

Source.

As a heads up @wannacfuture @whilefoo

Is it okay to make bot to respond about the events on config repo?

[ubiquibot]

! action returned an unexpected value

[0x4007]

Turns out we don't need PATs at all if the bot is installed on both repositories. Will update this specification to reflect this later.
Source.
As a heads up @wannacfuture @whilefoo

Is it okay to make bot to respond about the events on config repo?

I don't understand your question.

[wannacfuture]

You want to install bot on both repositories -> the user's repo and the config repo for compute delegating.

So the bot will react to the events on config repo as well.

[whilefoo]

Like I said here we would need another github app just for plugins because it needs additional permissions that we don't need for partner repos.
Also when the compute finishes you can't use Github app to trigger an event on calling repo because you're now in the context of plugin's repo, so like I recommended it would be better to just trigger an event on the plugin repo itself

[0x4007]

Like I said here we would need another github app just for plugins because it needs additional permissions that we don't need for partner repos.

We can enable workflow write permissions on our app. There's no issue with that.

Also when the compute finishes you can't use Github app to trigger an event on calling repo because you're now in the context of plugin's repo,

Workflow dispatch solves this. Please provide an example if I'm not understanding.

[whilefoo]

We can enable workflow write permissions on our app. There's no issue with that.

I think partners would prefer the bot have minimal permissions.

Workflow dispatch solves this. Please provide an example if I'm not understanding.

Workflow dispatch is for invoking the plugin, but when the plugin finishes and wants to send the result back via repository dispatch, it can't act on the behalf of the Github app but rather in the scope of the plugin repo.

Example:

• Repo A triggers Ubiquibot
• Ubiquibot sends workflow dispatch to Plugin A
• Plugin A triggers repository dispatch on Repo A -> this can't happen if plugin A repo doesn't have permissions for metadata and content read+write on Repo A. It can't act on the behalf of the Github app unless it has app's private key.

[ubiquibot]

# Comment event received without a recognized user command.

[ubiquibot]

@@ No latest assign event found. @@