duniter issueshttps://git.duniter.org/nodes/typescript/duniter/-/issues2020-10-04T18:51:17+02:00https://git.duniter.org/nodes/typescript/duniter/-/issues/981multicaster should not use explicitely `request` dependency2020-10-04T18:51:17+02:00Cédric Moreaumulticaster should not use explicitely `request` dependencyInstead, it should rely on generic forwarding methods fulfilled by some module. For example, multicaster could rely on `duniter-crawler` which has the logic for making HTTP requests.Instead, it should rely on generic forwarding methods fulfilled by some module. For example, multicaster could rely on `duniter-crawler` which has the logic for making HTTP requests.1.9https://git.duniter.org/nodes/typescript/duniter/-/issues/980Check that all the dependencies are necessary2018-01-27T07:27:44+01:00Cédric MoreauCheck that all the dependencies are necessaryIn each NPM module:
* `duniter`
* `duniter-common`
* `duniter-keypair`
* `duniter-crawler`
* `duniter-bma`
* `duniter-prover`
Check all the dependencies and devDependencies. If some dependencies can be removed or moved to devD...In each NPM module:
* `duniter`
* `duniter-common`
* `duniter-keypair`
* `duniter-crawler`
* `duniter-bma`
* `duniter-prover`
Check all the dependencies and devDependencies. If some dependencies can be removed or moved to devDependencies, that's cool because it won't be included in the in-production software. It will be lighter. Installation of each module will also be quicker.
Also, some modules might not be useful anymore. Some refactoring would be appreciated to remove `async` module for example.1.4.0https://git.duniter.org/nodes/typescript/duniter/-/issues/977Move fast block appliance to duniter core2018-01-27T07:27:44+01:00Cédric MoreauMove fast block appliance to duniter coreCurrently the fast appliance logic is in duniter-crawler, but that's a flaw: if this module implements incorrectly the duniter core rules, all the network might have inconsistencies.
It is better to give this work to duniter core.Currently the fast appliance logic is in duniter-crawler, but that's a flaw: if this module implements incorrectly the duniter core rules, all the network might have inconsistencies.
It is better to give this work to duniter core.1.3.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1037Migrate to TypeScript2018-01-27T07:27:42+01:00Cédric MoreauMigrate to TypeScriptFor security reasons, static typing would be a strong help.
Also, we could use async/await with Node.js 6 as TypeScript transpiled to es6 code supports async/await mechanisms.For security reasons, static typing would be a strong help.
Also, we could use async/await with Node.js 6 as TypeScript transpiled to es6 code supports async/await mechanisms.1.4.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1185refactoring ws2p connetion priorities2018-01-25T00:06:32+01:00Éloïsrefactoring ws2p connetion prioritiesDefinition of a priority level for each key:
by default the level is zero
If the key is a member: +1
If the key is preferred/privileged: +2
If the key is the same as yourself: +4 (for multi-node)Definition of a priority level for each key:
by default the level is zero
If the key is a member: +1
If the key is preferred/privileged: +2
If the key is the same as yourself: +4 (for multi-node)1.6.0ÉloïsÉloïshttps://git.duniter.org/nodes/typescript/duniter/-/issues/754Replace all the .catch() by try/catch2016-12-30T17:36:24+01:00Cédric MoreauReplace all the .catch() by try/catchBecause `.catch()` breaks the stack trace, this avoid us to deeply understand the cause of an error.
Example:
```js
return co(function*() {
yield server.initWithDAL();
yield configure(server, server.conf || {});
...Because `.catch()` breaks the stack trace, this avoid us to deeply understand the cause of an error.
Example:
```js
return co(function*() {
yield server.initWithDAL();
yield configure(server, server.conf || {});
yield server.loadConf();
cbArgs.length--;
cbArgs[cbArgs.length++] = server;
cbArgs[cbArgs.length++] = server.conf;
onService && onService(server);
return callback.apply(that, cbArgs);
})
.catch(function (err) {
server.disconnect();
throw Error(err);
});
```
Should be replaced by:
```js
return co(function*() {
try {
yield server.initWithDAL();
yield configure(server, server.conf || {});
yield server.loadConf();
cbArgs.length--;
cbArgs[cbArgs.length++] = server;
cbArgs[cbArgs.length++] = server.conf;
onService && onService(server);
return callback.apply(that, cbArgs);
} catch (e) {
server.disconnect();
throw e;
}
});
```0.80.0https://git.duniter.org/nodes/typescript/duniter/-/issues/749Use INDEX mechanism2016-12-23T16:25:28+01:00Cédric MoreauUse INDEX mechanismI've thought about a solution to express in a more formal way the protocol rules (local + global).
I call this new way the INDEX mechanism.
You can follow this issue to see the progress. I am planning to implement it in 13 steps:
...I've thought about a solution to express in a more formal way the protocol rules (local + global).
I call this new way the INDEX mechanism.
You can follow this issue to see the progress. I am planning to implement it in 13 steps:
1. Create a function(block) => local index.
2. Test 1. with few simple blocks.
3. Remplace local_rules.js code by local index checkings + rewrite the local rules in the protocol accordingly.
4. Split the local unit tests into separate files, instead of current big file which is not clear + add a file which tests the chaining of all the local rules.
5. Create the SQL tables of MISC index (Membership, Identity, Source, Certification).
6. Feed the index tables with *local* index as a new block is added to the blockchain.
7. Create a function(block) => global index.
8. Test 7. with few simple blocks.
9. Feed the index tables with *global* index as a new block is added to the blockchain.
10. Remplace the global_rules.js code by global index checkings + rewrite global rules in the protocol accordingly.
11. Handle the new revert algorithm, relying on indexes.
12. Remove deprecated fields + Remove deprecated functions (`getCurrentExcludingOrExpiring`, ...)
13. Handle index windowing (index becomes a flow, we don't need to store it fully, just a window)0.80.0Cédric MoreauCédric Moreauhttps://git.duniter.org/nodes/typescript/duniter/-/issues/708Certification with bad block hash > Code optimization + Fix log message2016-11-15T20:56:14+01:00Benoit LavenierCertification with bad block hash > Code optimization + Fix log messageWhen a certification has been done on an invalid block (bad buid), this is detected during signature validation, on the correct certification raw.
But NaCL verification could be skip if cert buid is compared to block buid.
The erro...When a certification has been done on an invalid block (bad buid), this is detected during signature validation, on the correct certification raw.
But NaCL verification could be skip if cert buid is compared to block buid.
The error message could be also be changed
https://git.duniter.org/nodes/typescript/duniter/-/issues/378HTTP API > wot/lookup meta.timestamp = blockUid ?2016-04-03T15:17:26+02:00Benoit LavenierHTTP API > wot/lookup meta.timestamp = blockUid ?A lookup like this one : http://twiced.fr:9330/wot/lookup/cgeek
will return:
> {
> "partial": false,
> "results":
> [
> {
> "pubkey": "HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk",
> "uids": [
> {...A lookup like this one : http://twiced.fr:9330/wot/lookup/cgeek
will return:
> {
> "partial": false,
> "results":
> [
> {
> "pubkey": "HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk",
> "uids": [
> {
> "uid": "cgeek",
> "meta":
> {
> "timestamp": "0-E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855"
> },
> "revoked": false,
> "revocation_sig": null,
> "self": "8muE9u43Y10ua2+CQPtksjxM6vKqQijbFP+8KVRR/hbBBvCwKFXEMN2EX5IlFmWbZOE9XU1ezVhTLmII7sQkAA==",
> "others": [ ]
> }
> ],
> "signed": [ ]
> }
> ]
> }
Why not to rename meta.timestamp into blockUid ?
0.20https://git.duniter.org/nodes/typescript/duniter/-/issues/136Remove `tsInterval` parameter2015-06-28T21:07:36+02:00Cédric MoreauRemove `tsInterval` parameterJust old and unused code.
Just old and unused code.
0.11.12https://git.duniter.org/nodes/typescript/duniter/-/issues/135Explicit call to start computation of new blocks2015-06-28T21:07:36+02:00Cédric MoreauExplicit call to start computation of new blocksCurrently, computation of new blocks is automatically started with ucoin instance services' init.
This feature should be explicitely called, so it won't be launched without explicit will.
Currently, computation of new blocks is automatically started with ucoin instance services' init.
This feature should be explicitely called, so it won't be launched without explicit will.
0.11.12