Example configuration:

{
    "rule": "voters",
    "mode": "moderation",
    "threshold": 9,
    "weights": [
        ["dlivemoderator1", 3],
        ["dlivemoderator2", 3],
        ["dlivemoderator3", 3],
        ["dliveadmin", 9],
        ["dlivepoweruser1", 1],
        ["dlivepoweruser2", 1],
        ["dlivepoweruser3", 1]
    ]
}

Example configuration:

{
    "rule": "reputation",
    "mode": "range",
    "min": 25,
    "max": 35
}

Example configuration:

{
    "rule": "votes_count",
    "mode": "equal", // more_than, less_then
    "value": 0
}

Example configuration:

{
    "rule": "voters",
    "mode": "none", // any, all
    "user": [
        "promobot",
        "upme"
    ]
}

Rule WeightForPeriod sums up only weights of previously passed voteorders, but does not add the weight of the new voteorder.

@noisy provided these images:
Here we can see that it passes as valid a voteorder that has weight higher than the total weekly maximum weight:

The rule fails after this voteorder was passed and confirmed by the daemon:

The feature: JSON reorganisation

It is important for me because: I don't care, lol

It is important for steem because: JSON created by Wise contains a lot of information that is indifferent to the computer.

"["v2:send_voteorder",{"delegator":"innuendo","ruleset":"Na wsparcie polskiej spolecznosci tagu pl-artykuly","author":"nisu","permlink":"shazam-recenzja-komiksu","weight":5000}]"

We have many variables that can be shortened. delegator - d, ruleset - r, author - a etc. We can save a lot of space on blockchain and users RC

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

When this is done, please rewrite "Common issues with unit tests" in CONTRIBUTING.md

• - define this task in more detailed way

As a user of Wise, I would like to have a possibility, to setup a different rules for posts posted via different interfaces. For example, I would like to reward higher authors which use alternative to Steemit interfaces, like Busy, Steempeak, eSteem, etc.

The problem: Integration tests fail

I did: run npm verify

I expected to see: all tests passed

Instead, I saw:

Failing tests:

• FakeApi / getWiseOperations / Returns ConfirmVoteBoundWithVote instead of pure ConfirmVote (when accepted = true)

• DirectBlockchainApi / getWiseOperations / Returns ConfirmVoteBoundWithVote instead of pure ConfirmVote (when accepted = true)

Version of steem-wise-core: 1.0.1

Version of nodejs: 9.11

Links to gist with output / logs (or at least a picture):https://gist.github.com/Jblew/ac2b991118fe53799440cad699a813f5

Links to steemd / steemit : -

As a developer I would like to have more info about how to contribute and work with Wise code base.

This can be added to 4th section of Wise Handbook

For devevelopers

1. Wise protocol - #18
2. The structure of the project — link's to all repositories with a short description of their purpose.
3. Instructions on writing synchronising the rules
4. Links to other docs

Wise needs more docs for various groups of users.
ELI5 for voters, quickstart guide for easy adoption, in-depth guides for devs.

Put a user in front of a https://github.com/noisy-witness/steem-wise-core/
Alice wants to be use wise, she want to give Bob, Carlos and Dave a way to vote on her behalf.
Eve is a poweruser, she wants to contribute by creating rules.
Alice needs an ELI5+quickstart guide, easy steps on how to deploy it and use it.
Bob and Carlos an ELI5 guide on how to vote, Dave and Eve need a guide for devs.

Currently there's some info in README, with mixed level of complexity and target groups.

Example configuration:

{
    "rule": "payout",
    "mode": "more_than", // less_then, equal
    "value": "10.00"
}

ISO 8601

As a developer who uses the steem-wise-core library I would like to have a possibility to read the docs of all of the WISE classes I use.

AC 1. All exported (in wise.ts) classes have documented: all classes, all methods, all constructors. Each with a simple example if possible.
AC 2. Documentation is automatically generated
AC 3. Documentation is hosted on Github Pages ("/docs" dir)

Example Configuration:

{
    "rule": "voting_power",
    "mode": "more_than", // less_then, equal
    "value": 90,
}

As a user (or potential contributor) I would like to have a possibility to easily be introduced into wise.

README should contain:
AC 1. Very short introduction to the idea of WISE (and the problems it solves)
AC 2. Links to landing-page, voter-page and handbook
AC 3. A brief description of how it works
AC 4. Short description of the protocol and a link to documentation of the protocol
AC 5. Structure of the WISe project (links to other repositories)
AC 6. Links to the docs of the library, of the protocol, to the handbook and to CONTRIB
AC 7. A single example of how to use the library in nodejs and another one for the browser.
AC 8. A graphics with milestones

An example beneficiary: #11

The problem: Voting power fetched by wise is inconsistent with steemd.com

I did:

I expected to see:

Instead, I saw:

Version of steem-wise-core:

Version of nodejs:

Links to gist with output / logs (or at least a picture):

Links to steemd / steemit :

• Change default api in wise-core to anyx.io
• Remember to upgrade Wise Hub

reason: https://steemit.com/steemit/@steemitdev/upcoming-changes-to-api-steemit-com

As a contributor I would like to have an overwiev over the structure of the project. I would also like an introduction to the tasks in the package.json and building pipeline

CONTRIB should contain:
AC 1. Structure of directories
AC 2. Description of all tasks
AC 3. Building and testing pipeline (manual)
AC 5. How to run unit (and in future system) tests
AC 6. How to submit pull requests

The feature: Ruleset loading time could be improved by using wise-sql

It is important for me because:

It is important for steem because:

Example configuration:

{
    "rule": "age_of_post",
    "mode": "older_than", // younger than
    "unit": "day",        // hours, minutes, seconds, weeks
    "value": 1
}

Example configuration of: 7 votes per week

{
    "rule": "weight",
    "mode": "multiple_votes_weight",
    "period": "week", // hours, minutes, seconds, weeks
    "period_value": 1,
    "weight": 70000
}

As a developer who works on WISE I would like to have an automated testing system that performs the usual actions of users and reports the results to me.
As a user I would like WISE to be free from annoying errors that appear after some releases.

AC 1. The system allows testing whole WISE (all repositories).
AC 2. The system allows testing different versions/branches of each repository against the others.
AC 3. The testing sequence covers synchronization of rules using cli, posting a voteorder using cli
AC 4. The system starts the daemon and analyzes the results
AC 5. The system analyzes the results that are put on blockchain

As a user I would like to have all informations about using WISE in a single place. Detailed and up-to-date.

AC 1. Separate repository on GitHub
AC 2. Hosted on GitHub Pages using Jekyll (some default theme with main colour changed to the Wise Violet) or maybe http://readthedocs.org ?

About Wise

Introduction about the idea of WISE (and what problem it solves) — it would be ideal if it contains parts of @noisy's prelection that he spoke on Warsaw Steem Meetup in July this year.

Sections

1. Instructions on voting using voter-page (with screenshots)
2. Instructions on using Wise Portal (purpose of it)
3. Instructions on using CLI (for advanced users)
   3.1. Instructions on running the daemon using cli and using the Docker.
   3.2. Rules
   3.2.1. Instructions on writing synchronising the rules
   3.2.2. Examples of joining multiple rules into one ruleset
   3.2.3. Description of each rule with examples

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

DirectBlockchainApi should perform a request to several apis in order (in a case when the previous api fails, the next is invoked).

In logs: as little "error" words as possible. Do not scare users if we can handle the situation.

Example configuration:

{
    "rule": "firstpost"
}

As a curious user or a developer who tries to understand I would like to have a possibility to understand the messages that WISE puts on blockchain.

AC 1. Hosted on Github Pages (/docs/protocol/v2, /docs/protocol/v1)
AC 2. V2 Protocol has very detailed docs: each part of the message has a description and info on purpose and usage.
AC 3. V1 Protocol docs are left as-is and are published only for curiosity.

As a developer who is doing a lot of manual work when publishing new versions of wise I would like to have a single script which would build, test & publish the whole ecosystem

(in order)
AC 1. The script takes new version number as an argument
AC 2. The script changes the version in package.json
AC 3. The script builds the library first, then tests it and proceeds only if the tests were ok
AC 4. The script creates tag in steem-wise-core
AC 5. The script publishes the library to npmjs registry

This is mostly internal draft, so sorry for Writing a non-english issue

Scenariusz: Wise umożliwia ustawianie reguł dla innych operacji niż vote

1. Zmiany w bibliotece steem-wise-core

1. Zmiany nazw:

   1. VoteOrder" -> ActionOrder
   2. ConfirmVote" -> ConfirmAction
   3. ConfirmVoteBoundWithVote -> ActionWithConfirmation

2. Zmiany w protokole generycznym:

   1. ConfirmVote zmieni nazwę na ConfirmAction, będzie miało identyczną strukturę.

   2. ConfirmVoteBoundWithVote zmieni nazwę na WiseActionWithConfirmation i będzie miało strukturę (zmiana nazwy pola):

      interface WiseActionWithConfirmation extends ConfirmAction {
          operation: SteemOperation
      }

   3. SendVoteorder zmieni nazwę na WiseAction i będzie miało następującą strukturę:

      interface WiseActionOrder {
          rulesetName: string;
          operation: steem.OperationWithDescriptor;
      }

   4. Ruleset uzyska następującą strukturę:

      interface Ruleset {
          name: string;
          operation_types: SteemOperationTypesAllowedByWise [];
          rules: Rule [];
      }

3. Dodanie protokołu v3:

   1. Stworzenie protokołu v3 (dla zachowania wstecznej kompatybilności kod protokołu v1 i v2 zostaną zachowane)

   2. Zamiast send_voteorder będzie wysyłane action_order, które będzie miało następującą strukturę:

      interface wise_action_order {
          delegator: string;
          ruleset: string;
          operation: VoteOperationWithDescriptor | CustomJsonOperationWithDescriptor | CreateAccountOperationWithDescriptor | ...AnySteemOperationWithDescriptor;
      }

   3. set_rules będzie miało następującą strukturę:

      interface wise_set_rules {
          voter: string;
          description?: string;
          rulesets: wise_ruleset[];
      }
      
      interface wise_ruleset {
          name: string;
      		operation_types: wise_allowed_operation_type [];
          rules: wise_rule [];
      }
      
      type wise_allowed_operation_type = "vote" | "custom_json" | "create_account" | ... /* other_but_the_list_should_not_be_too_permissive */;

   4. Testy nowego protokołu

4. Zmiany w protokole v2 i v1:

   1. tłumaczenie operacji na nowy generyczny protokół.
   2. testy sprawdzające na przykładach poprawność tłumaczenia

5. Zmiany w Validatorze:

   1. Kod sprawdzający, czy operacja należy do listy operation_types w regule.

6. Zmiany w regułach

   1. Każda istniejąca regułą będzie miała dodatkowy validator rulesetu, który będzie sprawdzał, czy ta reguła potrafi przetwarzać wszystkie typy operacji zezwolone w tym rulesecie.
   2. Każda istniejąca reguła będzie musiała obsługiwać steem.VoteOperation zamiast SendVoteorder (bardzo podobna struktura)
   3. Dodanie nowych reguł dla każdego nowego typu operacji

7. Zmiany w synchronizatorze: tylko zmiany nazw

8. Zmiany w RulesUpdater: dostosowanie do nowego generycznego protokołu (głównie zmiany nazw + zmiana struktury Rulesetu z tablicy na obiekt)

9. Wydzielenie kodu odpowiedzialnego za synchronizację blockchainu do biblioteki steem-efficient-stream

Pełna wsteczna kompatybilność. Z perspektywy użytkownika działa tak samo.

2. Zmiany w bibliotece steem-wise-cli

1. Nowa subkomenda "migrate-protocol-to-v3", która migruje stare pliki z regułami. Po prostu do każdego zestawu reguł dodaje: operation_types: ["vote"]
2. Subkomenda "upload-rules"
   1. Obsługuje stary format migrując go w locie, ale sugeruje użytkownikowi wykonanie komendy "migrate-protocol-to-v3"
3. Subkomenda "send-voteorder" pozostaje i działa tak jak poprzednio: zamiast obiektu SendVoteorder generuje WiseActionOrder z operacją "vote" + dodatkowo wyświetla informację o nowej komendzie "send-actionorder"
4. Nowa komenda send-actionorder, która jest identyczna jak send-voteorder, tylko przyjmuje jako parametr obiekt typu "WiseActionOrder"

Pełna wsteczna kompatybilność. Z perspektywy użytkownika działa tak samo.

3. Zmiany w steem-wise-sql

Nie jest potrzebna wsteczna kompatybilność, bo narazie tylko wise-hub korzysta z sql-a

1. Wykorzystanie UniversalSynchronizer z biblioteki steem-wise-core zamiast własnego synchronizatora (który duplikuje kod)
2. Pusher automatycznie wygeneruje operacje o nowym typie
3. Ponowna synchronizacja blockchainu jeśli to jest szybsze niż migracja, a przeciwnym przypadku prosta migracja
4. Przechowywanie operacji wise w formacie "raw" w celu umożliwienia przyszłych migracji

4. Zmiany w wise-hub

Wise hub tylko będzie wyświetlał nowe rodzaje operacji, ale nie będzie ich narazie przetwarzał

1. Frontend
   1. HistoryEntryComponent będzie wyświetlać więcej rodzajów operacji
   2. PersonComponent będzie wyświetlać nazwy nowych operacji
   3. Ustawianie reguł nadal tylko dla vote
   4. RulesetsView będzie wyświetlał zestawy reguł z operacjami innymi niż vote jako zwinięty custom_json
2. Backend/publisher
   1. Publisher będzie odrzucał ActionOrder, który ma inny rodzaj operacji niż "vote"
3. Backend/api
   1. DaemonManager i Daemon — trzeba zmienić nazwy funkcji/obiektów ze steem-wise-core
   2. Daemon — będzie odrzucać ActionOrdery dla innych operacji niż vote

5. Zmiany w steem-wise-voter-page

Tylko zaaktualizowanie kodu do innych nazw funkcji/obiektów w bibliotece steem-wise-core.

5. Aktualizacja manuala

As a developer, who is still trying to solve wise-team/steem-wise-cli#9 I would like to have a possibility to turn on logging with different levels of verbosity

AC1. Find good js logging framework
AC2. Logs should be collected in steem-wise-core
AC3. There should be "-v" switch in steem-wise-cli tool that turns on logging both in cli and core packages

TODO:

• - grant Travis access to steem-wise-core
• - decide on semver versioning strategy
• - implement semantic-release system
• - write .travis.yml
  • - building
  • - unit testing
  • - integration testing
  • - release
  • - update steem-wise-core version in dependency repositories based on branches
• - fix npm publish key error
• - resolve collisions of concurrently run integration test (per branch ENVs that defines test account)