← Back to Blog

Weekly Project Update #10

The one where the CLI gets weird.

2 min read • BD Tinsley

Overview

I've continued the process of peicing together my CLI proof of concept for decx.press, but I'm noticing strange behaviors that are burning more of my time than I would have hoped. There's a ton of elements working together that are making it difficult to diagnose what the problem may be. I'll do a quick rundown of what I've done and list off the dependencies and where I think the issue is.

I've put together a basic CLI that has various commands:

  • init: initialize the decx.press CLI, which includes configuring it and setting up a wallet
  • config: further fine-grained control over the config file, which is stored in the user's system where it allows you to get and set network, gas priority and other minor details
  • wallet: see current wallet details, add a new wallet, set a default wallet
  • health: check the health of the decx.press API, which in the current state is being run in a different terminal window on localhost
  • help: list out all available commands, what they do and some examples of how to use them

So to initialize the CLI, after downloading, the user would type:

$ decx init

and it would walk the user through the minimal steps to ensure they can work with decx.press.

I've began working on the press command and the strange behavior I've noticed is I can easily press 1 or 2 small bits of content in under 2 minutes for less than a penny. Nice! But anything beyond that, the network hangs and the pressing never goes through. I have some theories why this is happening, but diagnosing it is proving to be difficult. I do have a timeout setup so that the CLI isn't hanging forever. Intially I set it for 30 minutes, but the more I played with it, the more I realized that 3 minutes was all I needed to determine if it was going to go through or not.

I've also tinkered with the API endpoints, which initially just took a string on the /press/:string endpoint and returned the final hashed content when it was done. Now, I've split it into /press/:string, where the user sends a string to be pressed which automatically closes once it has a transaction ID; /press/status/:transactionId where the user provides the generated transaction ID and checks in on the status of a pressing; and /press/hash/:hashId where the user can get the details of a completed pressing. I'm still finding it hanging after a few pressings, but at least I have better control over where in the process it is.

Where I think the real issue lies is in the network requirments. I think the gas fees are too low for my pressings to be prioritized on-chain, and they are ignored by the validators because it's not worth the effort for them. This may be a big liability because decx.press has to be inexpensive in order to be valuable. I won't add unneccessary computing just so it will transact. I'll keep working at it.

Last Week

What I Said I'd Do

  • Finish the wallet solution [CLI#2]
  • Start work on the non-iteractive pressing functionality [CLI#3]

Next Week

  • Finish up the work on the pressing functionality, finding a consistent way to press content [CLI#3]

Blockers

None.

Reflections on Process

I'm back into the swing of things post spring break. Things feel quite murky at the moment, but I'm optimisitic in the process. It feels like I'm so close to breaking through.