paritytech / substrate-archive

Blockchain Indexing Engine

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Maintenance Status: Unmaintained. Please fork.

jsdw opened this issue · comments

We at Parity haven't been able to dedicate enough time and attention to Substrate Archive lately, so this is a call for maintainers.

If you're interested in helping to take the reigns on this project, please reply to this issue and let's have a chat!

commented

Would like to help contribute(not as a maintainer), my team is currently using substrate-archive in production. I recently created a PR: #462 and a comment: #342 (comment) I think these may helpful for others.

Thankyou @xcaptain, noted :)

commented

Hi @jsdw, I want to contribute to open source in Paritytech ! Where is the best way to chat for you?

Just to update anybody viewing this issue on my current feelings here:

  • Substrate-archive will require a fair chunk of time and effort to upgrade to ParityDB eventually, as it connects direct to the DB and currently supports RocksDB for that purpose.
  • Archive is also quite opionated about what it does with the information it decodes from a node; it slaps it into a Postgres DB with a certain schema. I think there is value in separating these two things, and having a tool that can stream data from a node but isn't opinionated on where it goes. But this would be more work, of course.
  • We have quite a lot of other projects/work to focus on at the moment.
  • Handing over maintainance rights to others would still leave us as the bottleneck; we'd need to review PRs and have some role in the future direction of Archive, since it is still a Parity product.

Thus, I'd propose that anybody who is keen on stepping up and maintaining this project creates a fork of it and builds off it in whatever direction they'd like to in their own space. if one such fork becomes popular (or several, with different aims and strengths), I expect we'd be happy to point at it from here!

I'll leave this issue open so that people can see this, and we can mull over it some more, but the TL;DR is that I think forks would be a better path forward than giving away maintenance rights at the mo!

Hi, our team is working on the substrate archiver, and our product will heavily reply to it as infrastructure. We would like to make a contribution to this repo and maintain it. Could you please give us a roadmap about improvements and developments on the archiver? And how could we find you? Thanks.

See my above comment; I'd suggest that if you're interested in building off this project that you create a fork of it and go from there. We do not have the bandwidth to maintain or oversee work on the project at the moment, so this is the best way to make progress on it :)

If you (or anybody else) creates a successful fork, we'll consider pointing people at it from this repo, too!

is it possible to still run this? i need all balance related transfers and event from genesis block and upload it to my postgresql remote server database(~17million blocks from genesis)

All I can suggest is to have a go at running it; as long as the node is using RocksDB and not ParityDB, I can't think of any reason why it wouldn't work still :)