snapshot-labs / snapshot-hub Goto Github PK

For some reason I got this error while I'm sure I send way less than 32 requests for 12 sec, something is wrong is rate limit helper

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Query strategies by id

Reason:

{
  "error": "unauthorized",
  "error_description": {
    "cause": {
      "code": "ER_DATA_TOO_LONG",
      "errno": 1406,
      "sqlMessage": "Data too long for column 'type' at row 1",
      "sqlState": "22001",
      "index": 0,
      "sql": "\n    UPDATE messages SET type = 'archive-proposal' WHERE id = 'QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj' AND type = 'proposal' LIMIT 1;\n    DELETE FROM proposals WHERE id = 'QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj' LIMIT 1;\n    DELETE FROM votes WHERE proposal = 'QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj';\n    DELETE FROM events WHERE id = 'proposal/QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj';\n    INSERT IGNORE INTO events SET `id` = 'proposal/QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj', `space` = 'mktcode.eth', `event` = 'proposal/deleted', `expire` = 1633880551;\n  "
    },
    "isOperational": true,
    "code": "ER_DATA_TOO_LONG",
    "errno": 1406,
    "sqlMessage": "Data too long for column 'type' at row 1",
    "sqlState": "22001",
    "index": 0,
    "sql": "\n    UPDATE messages SET type = 'archive-proposal' WHERE id = 'QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj' AND type = 'proposal' LIMIT 1;\n    DELETE FROM proposals WHERE id = 'QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj' LIMIT 1;\n    DELETE FROM votes WHERE proposal = 'QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj';\n    DELETE FROM events WHERE id = 'proposal/QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj';\n    INSERT IGNORE INTO events SET `id` = 'proposal/QmVtP79mxoXFi7FncVgm7wC65HW2gTvGbyvNomGm6TkYsj', `space` = 'mktcode.eth', `event` = 'proposal/deleted', `expire` = 1633880551;\n  "
  }
}

Casting a vote where the address is a contract will trigger isValidSignature but only on mainnet.

The network could be gathered from the proposal and then implemented in verifySignature:

const proposal = await getProposal(msg.space, msg.payload.proposal);

if (!(await verifySignature(body.address, body.sig, hashMessage(body.msg)), proposal.network))
    return Promise.reject('wrong signature');

This is needed for snapshot-labs/snapshot#815

It should only be possible to vote with a value greater than zero in the choice object. Sending a vote like this f.e { "1": -1 } should throw an error.

When someone voting multiple time we store all the votes, instead we should update latest vote and make sure we have only latest vote cast for an address

Expected behavior

When canceling a login the account should stop loading.

Actual behavior

When canceling a login the account would stay in loading state.

AirSwap is working on a way for governance participants to claim earnings based on voting weight. To achieve this without adding trusted process or infrastructure, voter (author) address and weight (score) would be included in each certified vote and be subsequently verifiable by a smart contract.

Given that the relayer certifies each vote, author and score could be included in the message that is signed by the relayer when each vote is submitted. The relayer is doing this work here.

const relayerSig = await relayer.signMessage(authorIpfsRes);
const relayerIpfsRes = await pinJson(`snapshot/${relayerSig}`, {
  address: relayer.address,
  msg: authorIpfsRes,
  sig: relayerSig,
  version: '2'
});

To determine score, the snapshot.js module has a getScores function.

const scores: any = await getScores(
  space.key,
  space.strategies,
  space.network,
  getProvider(space.network),
  Object.values(proposals).map((proposal: any) => proposal.address)
);

The relayer could then include the author and score in the message it signs.

const message = JSON.stringify({ author, score, ipfsHash: authorIpfsRes });
const relayerSig = await relayer.signMessage(message);
const relayerIpfsRes = await pinJson(`snapshot/${relayerSig}`, {
  address: relayer.address,
  msg: message,
  sig: relayerSig,
  version: '2'
});

The contract verification function would either take msg as an argument and parse the author and score out of it...

function verify(bytes memory msg, bytes memory sig) public {}

or take author and score as arguments and reconstruct the msg JSON string prior to verifying it.

function verify(address author, uint256 score, bytes ipfsHash, bytes memory signature) public {}

Alternatively, if score is included in the author signed message, then both the author and relayer signatures could be submitted to the contract. In this case, the contract would need to parse the author and score out of the author message, and then generate the CID of the author data to ensure it matches the authorIpfsRes found in the relayerIpfsRes message.

These are just initial thoughts but really appreciate you guys taking a look. Thanks 🙌

In #264 I added a comment for anyone stumbling about this duplicated function.

This issue is for our backlog.

We need make sure when someone send a proposal with type "basic" that there is only 3 choices with text "For", "Against", "Abstain"

Either the hub should run with a MySQL 8 database or a note should be placed in the readme or this needs to be a more explicit/enforced dependency.

On a new Linux laptop (Mint 20) installing MySQL will install version 8. Running the hub will fail due to incompatibilities in the mysql package being used.

mysqljs/mysql#1959
mysqljs/mysql#2233

This workaround fixes the issue though: https://stackoverflow.com/a/50377944/2560696

We should remove vue-cli-service and all the pkg related to Vue and run TS with tsc directly
https://github.com/snapshot-labs/snapshot-hub/blob/master/package.json#L7-L10

Behavior

Currently, aside from storing voting data on IPFS, this data is also retained in a centralized database. This is useful to the developer, because now the GraphQL API can include voting power without relying on the availability of the Scores API, which stability is often limited by the blockchain provider. However, the data the GraphQL API returns doesn't correspond with the results of the Scores API.

Explanation

The current implementation of the GraphQL API is limited because the scores are only calculated correctly if the proposal state is closed. That means that the data the API returns is not reliable unless the proposal has been expired (and all votes are counted).

When looking at the following lines the scores are only updated when the scores state is final (which depends on the proposal state to be closed).

Further more, looking at the following code we can see that the getProposalScores() is called on the proposal/end event, further indicating the scores are not reliable up to that point.

There is also this recursive method, that updates the scores for a proposal after its created (if you're lucky), which we should probably get rid of or do a better implementation.

Solution

The best way I see to resolve the reliability issues is to create a proposal/voted event that the event handler can use to recalculate the scores. Together, with the scores_state and scores_updated attributes this should give the develop enough data to show the current polls before they are made final.

We should probably also think about retrying after error behavior in the custom built event handler, but that is relevant for all events. Furthermore, I think this behavior should be better documented.

yarn start

        throw new TypeError('Invalid connection string!');
              ^

TypeError: Invalid connection string!

How can I do it?

Half of the time when trying to submit a proposal (with a delay) I'm getting this error. There doesn't seem to be a buffer on the backend?

Requires #226

The search string should be matched to space names.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>whitesource/merge-confidence:beta)

This is a feature request to extend the GraphQL API to add support for querying aggregate counts for the existing types (votes, spaces, follows, etc.)

This would make computing metrics of Snapshot entities easier. For example, the proposals_1d metric returned by the explore endpoint could be queried via the GraphL API.

The snapshot twitter bot posts weekly and monthly summaries. Pulling data for the summaries via aggregates would be a big improvement as well.

An example query might look like this:

query VoteCount($id: String, $date: String) {
  vote_aggregate(where: {space: $id, created_gte: $date}) { count }
}

# response
{
  "data": {
    "vote_aggregate": {
      "count": 92
    }
  }
}

Actual behavior

I got the following error when trying to run hub service

Steps to reproduce the behavior

1. git clone the repo
2. yarn install
3. yarn start

While creating a proposal, right now if we pass different strategies to the hub, we enforce the same strategies as space, but IPFS still has the strategies that the user signs and it is confusing, we should return an error if different strategies are passed

Update: Now we store the same strategies as space but signed message may contain original strategies than space strategies

First step is to find out which voting types require a positive number as choice value
Second step is to enforce positive numbers on the hub for these votes

Instead of having daily and monthly limit, we should limit proposal based on the number of active proposals, we should cap it to 64 to start.

snapshot-labs/snapshot#955 (comment)

Helpful to fix snapshot-labs/snapshot#670

Now proposals are purely ordered by creation date, but we should also consider the status and show active proposals first.

https://github.com/balancer-labs/snapshot-hub/blob/9b40e7d73b8af25205b9849d0987b1e55bbaa5fe/server/index.ts#L121

variable ts is got by toFixed(), which returns a string type.
suppose ts = 1606187922, then ts + 300 => 1606187922300, not 1606188222 we expected.

Requires #226

And max 320 proposals per month

see

• https://github.com/snapshot-labs/snapshot-docs/blob/master/guides/archived/hub-api.md
• https://docs.snapshot.org/guides/archived/hub-api

but when I follow a link, e.g. https://hub.snapshot.page/api/spaces

That page seems to be down. In fact, all of https://hub.snapshot.page seems to be down.

Expected behavior

for example, in BitQuery
https://graphql.bitquery.io/ide/kB1xFizycB/qHRgRPz4gD

Actual behavior

Right now, I can't get distinct users amount in a specific proposal. Or the amount of specific token participate in one proposal.

Steps to reproduce the behavior

Expected behavior

EIP1271 signature verifier supported for all Smart Contract wallet implementations.

Actual behavior

EIP1271 signature verifier is rejected from destination contract due wrong ABI.

Ref to EIP1271 history that this was in proposal and has been implemented by some wallets – ethereum/EIPs@026675e#diff-5641e34a6f945196e79a576e6406eb4690ee5e34624ccedfcc8e42157e23bd06.

Steps to reproduce the behavior

Try to verify signed message signature from Pillar Wallet that has Smart Contract wallets supporting other version of EIP1271.

We should be able to query for proposals based on their type, example: get proposals where type = "quadratic"

NETWORK

SNAPSHOT_URI:

and now there's DEFAULT_NETWORK:

This is a bit confusing but NETWORK could actually be removed and replaced by SNAPSHOT_URI. It does nothing more than building the frontend URL for proposal links and/or push notifications.

Originally posted by @mktcode in #210 (comment)

We should verify when a new proposal is created if the space settings include a voting delay and voting period. If its the case we should make sure the start and end params of the proposals are have a difference exactly equal to the voting period, and if the timestamp of the proposal and start of the proposal have a difference equal to voting delay.

Expected behavior

Should not allow invalid address

Actual behavior

It's allowing invalid address

We need to move this ordering logic to spaces query on the hub https://github.com/snapshot-labs/snapshot/blob/f59b21b72ce6824a7b9d617caddb606faf08d3fe/src/composables/useApp.ts#L79