Roadmap discussion

[lpoirothattermann]

Hi,

I'm new to the project and would like to help.
But there is no roadmap or "task list" defined. It's not easy for new contributors to "onboard".

If someone that tracks the project for a long time (@serhack ?) can do this, a "simple" task list would be enough in a first step. That would be very appreciable.

[recanman]

Look at issues, those are what can be done to contribute.

@serhack can you close this?

[BrianHenryIE]

I started work on the RPC client classes to get them strongly typed and unit tested.

https://github.com/BrianHenryIE/bh-php-monero-daemon-rpc

I'll do more work on it as the mood takes me. Hopefully will have the "work in progress" notice removed by Christmas!

[recanman]

Thank you for your help.

[BrianHenryIE]

I did some more work on that today. I got some neat tests running where the RPC response was verified against the CLI output from monerod.

I think the RPC clients should be a different package to this one. The math content of this package isn't needed when using the RPC functions. I notice the Python RPC client is actually part of the monero-project/monero repo.

How do you feel about using external libraries instead of base58.php, ed25519.php and SHA3.php?

A quick search finds these decent looking libraries:

• 0xbb/php-sha3
• tuupola/base58
• simplito/elliptic-php

That would pare this package down to a size much easier to focus on when improving PhpDoc etc.

I'm also almost finished writing a client for xmrchain.net and its implementations: bh-php-monero-explorer

As I said above, this is something I dip into every now and then and will probably take many months to complete. But you can also see I'm aiming for very high code quality.

My real goal is to start writing PRs against the WordPress/WooCommerce plugin.

[recanman]

Yes, that is currently on my list of items to replace the libraries. In #141, I've deleted SHA3.php and replaced it with kornrunner/keccak.

I tried out tuupola/base58, but the current base58.php does a few conversions and padding, which I skipped for now.
I did not look for an ed25519 library replacement, I will look into simplito/elliptic-php.

Most of my PHP experience is out of PHP 8, so I'm quite new to strict types, and I've been wondering how to strictly-type associative arrays. Your xmrchain.net client repository is very helpful.

[BrianHenryIE]

I did a bunch more work on Daemon and Wallet RPC classes yesterday.

But then, when I started to write Wallet tests monerod segfaulted and when I rebooted my laptop it wouldn’t turn back on, so now it’s now away with Apple for repair!

@serhack Would you please take a look at https://github.com/BrianHenryIE/bh-php-monero-rpc and consider moving the repo into the monero-integrations organization (and renaming, obviously)? I think it should be its own repo, separate from this one but required by it.

It’s not “complete” but I think it’s as good as or better than the existing code (naturally, since that was the starting point!).

There is currently a PHP 8 requirement due to the JSON RPC library I’m using. And to reiterate my thoughts on PHP 7 from the other thread, nobody in their right mind is starting a new project using PHP 7 these days, and if they really need it, there is a tool called Rector which can transpile your code down to older PHP versions.

And @recanman , thanks for the motivation!

[recanman]

You're welcome. How your computer 'stopped working' after monerod segfaulted is quite odd, I'd like to hear more on that if it ends up working again.

I've taken a look at elliptic-php, and it is a nice library, but like in base58.php, there are many helper functions that are included with the library. I am not a cryptographer, so I think it might be better to leave ed25519.php where it is right now, and add PHPDoc strings (which I'm doing in #140).

[serhack]

Weird to read about your computer broken after running monerod. I'm guessing it probably corrupted the entire filesystem (although a user-space program should never be able to corrupt the fs). Keep us updated about it.

Regarding the bh-php-monero-rpc, it's a great repository but I'm still having doubts about its utility. What advantages could you have by using bh-php-monero-rpc instead of monerophp? If there's a real advantage, I'd like to have that in the monerophp repo after I merge all the PR.

[lpoirothattermann]

@serhack Would you please take a look at https://github.com/BrianHenryIE/bh-php-monero-rpc and consider moving the repo into the monero-integrations organization (and renaming, obviously)? I think it should be its own repo, separate from this one but required by it.

Why not merge bh-php-monero-rpc into monerophp?

[recanman]

I think it might be better to leave them separate for now, and merge some changes from the bh-php-monero-rpc repository into here selectively. I will get some time this week, and finish off #140. Then, I will abstract (according to PSR standards) #138 and get it ready to merge. The reason I'm focusing on documentation is because it is inconsistent, and not helpful. Being able to have intellisense in the IDE saves hours of time, so auto-generated documentation based on parameters will be very helpful.

The biggest things remaining after that are strong types and unit tests. Unit tests shouldn't be implemented before strong types.
This is something I do not have much experience with, so I will use bh-php-monero-rpc as a reference.
Unit tests are just a matter of tedious work.

[BrianHenryIE]

I didn't mean to suggest monerod had broken my computer, I thought the issue with the computer was causing monerod to crash. Turns out it's an issue with M1 Macs (with a solution!).

I'd like to have that in the monerophp repo

The point in Composer is to allow splitting projects into packages which can then be reused independently. Each project has a "dependency tree". E.g. here's the JsonRpc library I'm using:

$ composer show --tree --no-dev
psr/http-factory 1.0.2 Common interfaces for PSR-7 HTTP message factories
├──php >=7.0.0
└──psr/http-message ^1.0 || ^2.0
   └──php ^7.2 || ^8.0
psr/http-message 1.1 Common interface for HTTP messages
└──php ^7.2 || ^8.0
thecodingmachine/safe v2.5.0 PHP core functions that throw exceptions instead of returning FALSE on error
└──php ^8.0

You can see there that psr/http-message doesn't depending on anything (except php), but psr/http-factory depends on psr/http-message. I.e. I can use psr/http-message on its own, when that's all I need, but it is automatically pulled in anytime I say I need psr/http-factory.

In the case ofmonero-integrations/monerophp, I see that the daemon rpc clients are something that might be used independently of the math code, and vice-versa. I expect I will need the math code when using the http Monero Explorer but not the rpc code, so I'd go so far as to suggest another fork of this repo which would then contain only the math code. This parent repo can still pull in all the monero php libraries under the one umbrella, but they could each be used independently.

If that were the case, Guzzle could reasonably be used in this repo.

So a consumer running composer install monero-integrations/monerophp would get something like this (abbreviated):

$ composer show --tree --no-dev
monero-integrations/monerophp 1.0.2  Monero PHP library + JsonRPC Client 
├──php >=7.0.0
├──monero-integrations/monero-rpc 1.0 Monero JsonRPC Client 
│  └──php ^8.0
├──monero-integrations/monero-math 1.0 Monero PHP library
│  ├──php ^7.2 || ^8.0
│  └──kornrunner/keccak ^1.1 Pure PHP implementation of Keccak (SHA-3) 
├──BrianHenryIE/bh-php-monero-explorer 1.0 Onion Monero Blockchain Explorer Client
│  └──php ^7.4 || ^8.0
└──guzzlehttp/guzzle 7.8.0 Guzzle is a PHP HTTP client library
   ├──ext-json *
   ├──guzzlehttp/promises ^1.5.3 || ^2.0.1
   │  └──php ^7.2.5 || ^8.0 
   ├──guzzlehttp/psr7 ^1.9.1 || ^2.5.1
   │  ├──php ^7.2.5 || ^8.0
   │  ├──psr/http-factory ^1.0
   │  │  ├──php >=7.0.0
   │  │  └──psr/http-message ^1.0 || ^2.0
   │  │     └──php ^7.2 || ^8.0
   │  ├──psr/http-message ^1.1 || ^2.0
   │  │  └──php ^7.2 || ^8.0
   │  └──ralouphie/getallheaders ^3.0
   │     └──php >=5.6
   ├──php ^7.2.5 || ^8.0
   ├──psr/http-client ^1.0
   │  ├──php ^7.0 || ^8.0
   │  └──psr/http-message ^1.0 || ^2.0
   │     └──php ^7.2 || ^8.0
   └──symfony/deprecation-contracts ^2.2 || ^3.0
      └──php >=8.1

Again, I'm happy to move it under the monero-integrations namespace, but I am sure it should be its own package.

It's also much easier to approach smaller libraries, both as a consumer and a contributor. BrianHenryIE/bh-php-monero-rpc is already at about 35 classes and I expect that to at least double.

Smaller packages are easier to understand, naturally. This makes them easier to contribute to. The separation of concerns also makes them easier to contribute to – I've much less imposter syndrome contributing to an rpc wrapper than an cryptographic library. Smaller packages can be used independently to keep installed code low, so when something is wrong, I'm not searching through dead code to try understand where the problem is.

Earlier I misinterpreted the question "What advantages...?" as asking why not use the current untyped stdclass responses, so I made this video showing the intellisense autocomplete and inline documentation:

monero-intellisense.mp4

Really, there's no disadvantage to breaking this library into smaller packages, because someone installing this will still get all of them automatically.

[lpoirothattermann]

I'm agree that we should split current package into multiple parts, not because it's easier to manage, with good project structure code wouldn't be messy, but because other people could want to use for example monero-integrations/monero-math or monero-integrations/monero-rpc for their own projects.
But I don't get way you want to create a new package under monero-intergrations that will just be the overall the same this one.

We could maybe start to create dependencies packages like monero-integrations/monero-math (the exhaustive list of package should be defined first) and once the package look finished/"ready to be use" in monero-integrations/monerophp we require it in composer and start to implement it, step by step, dependency package by dependency package.

[recanman]

After looking into it more closely, I think that it would be better to work on bh-php-monero-rpc, and then split into packages and merge here.

[BrianHenryIE]

I have some ideas to make development go faster... although I've been working on other projects (including contributing to the PhpJsonRpc dependency that bh-php-monero-rpc uses).

The bh-php-monero-rpc Contributing section isn't 100% correct – that was what I was working on when my laptop hit the bucket.

Since bh-php-monero-rpc is using the PSR packages, it should be possible to extend a Psr\Http\Client\ClientInterface so the response is written to disk each time. Then we're auto-generating the tests/_data json files.

I had been using jacobdekeizer.github.io/json-to-php-generator website/web-app to generate the PHP, but no doubt there is an actual PHP library which can similarly input JSON and output PHP, maybe needing Swagger as a mid-step.

I think some ChatGPT/LLM can be leveraged for writing the docblock comments, with someone with more experience/authority (obviously looking at you @serhack !) to review that each is correct.

The hard part then is setting up the tests against the Monero daemon. Obviously needs to not use mainnet, and AIUI testnet is for development of Monero itself, so stagenet seems to be the correct network to use. While I say this is the hard part, I think it is a particularly valuable part of the documentation.

One bad thing is, it seems the PhpJsonRpc dependency depends on PHP 8.1 now, which I didn't realise before. Since there's so much development work to do still, I'm not in a hurry to address that. I presume, but I'm not certain, there is a way to publish parallel versions of packages on Packagist for different PHP versions, i.e. what I said previously about Rector but done at the package level rather than the consumer level.

Sorry for the brain-dump! I pushed a couple of commits to bh-php-monero-rpc just now – only major thing was the PhpJsonRpc changes.

I think another reason to move brianhenryie/bh-php-monero-rpc to monero-integrations/php-monero-rpc (or whatever) is so contributing it looks like it's contributing to a community project and not just Brian Henry's project.

[recanman]

Great, thank you. Other than testing for the currently-opened issues and making sure that those problems don't exist, is there anything else that should be done? I see in the repository that you said that one class just returns stdClass, so types are a good point to start from.