BD Tinsley

Weekly Project Update #12

BD Tinsley — Wed, 16 Apr 2025 19:26:10 GMT

Overview

With the final aspects of the API wrapped up, I was able to diagnose the true issue to the press command only occasionally working. There was a mismatch of transaction, content and request hashes and the API would confuse them with each other. Now I have a full fledged CLI for pressing that hits the /press endpoint, which generates a transaction hash that can be observed and verified on etherscan, and a request hash that the CLI will take and poll the /status/:requestId endpoint every 10 seconds until the transaction returns with a success or failure status. If it fails, it will give some guess as to why it failed, most likely the transaction hit the gas limit; if it succeeds, it returns the final content hash to be shared for releasing.

The final bits now come down to building out the release command, so that a recipient of a bit of content can decrypt it. There are some unexpected issues with my current implementation and how I want the release command to work, which primarily comes down to the wallet address not being a reliable key to encrypt content with. I think I have a workaround that will incorporate the access layer dream, which will neatly wrap up all the final bits into the end result. Beyond that, it's some ergonomics in adding interactive mode to certain commands and documentation and this proof of concept is done.

Last Week

Finish up the work on the pressing functionality, finding a consistent way to press content [CLI#6] (almost done with this)

Merge in the pressing functionality [CLI#6]

Completed the storage functionality for pressed (& TBD released) content [CLI#4]

Additional Accomplishments

Built out a list command to see all the prior pressings [CLI#5]

Next Week

This upcoming week will be scant due to some pressing matters in my life. I can't commit to full feature builds but will spend some time figuring out how the releasing [CLI#8] methodology will work. Likely, I'll have to wrap the access layer functionality [PRESS#36] into it, which will be the last remaning high-priority issues to build. I can come up with the plan now and execute when I have more time to dedicate.

Blockers

None.

Reflections on Process

It seems like I'm at the last clearing and I see one last glimpse of the end goal, and it's closer and bigger than I've seen before. There are more perils in front of me, some known, some unknown, but it feels like I'm finally nearing the end.

Weekly Project Update #11

BD Tinsley — Thu, 10 Apr 2025 16:26:10 GMT

Overview

I hinted at the need for a refactor last week, and that's what I ended up doing. Diagnosing the issues in the API were tricky, which could be summed up as it would only occassionally work. Breaking it apart helped me realize a few things:

The wallet connected to the API, which was only there to verify curl routes were working, was taking precedence for transactions, not the wallet connected to the CLI.
The transaction hash generated was not a valid Ethereum transaction hash, so verifying the transaction completed was impossible.
The gas fees were, in fact, too low to prioritize the transaction on chain, so it was stuck forever in the mempool.

I'm glad I did this, as it makes the API more robust, easier to diagnose and much simpler to add to in the future. I've gone from an api directory structure of:

api/
├── contract-abi.json # decxpress functionality abstracted into JSON
├── server.ts         # all the functionality
└── test-client.js    # all tests for the API

api/
├── controllers/
│   ├── balanceController.ts  # logic for /balance endpoint
│   ├── hashController.ts     # logic for /hash/:hash endpoint
│   ├── pressController.ts    # logic for /press endpoint
│   ├── releaseController.ts  # logic for /release endpoint
│   ├── statusController.ts   # logic for /status endpoint
├── middleware/
│   ├── errorHandler.ts       # consistent formatting for errors
│   ├── requestLogger.ts      # consistent formatting for logged messages
├── routes/
│   ├── balance.ts            # definition for /balance endpoint
│   ├── hash.ts               # definition for /hash/:hash endpoint
│   ├── press.ts              # definition for /press endpoint
│   ├── release.ts            # definition for /release endpoint
│   ├── status.ts             # definition for /status endpoint
├── services/
│   ├── transactionStore.ts   # comprehensive logic & logging for a transaction
│   ├── walletService.ts      # comprehensive logic & logging for wallet connection
├── contract-abi.json         # decxpress functionality abstracted into JSON
├── server.ts                 # minimal init file to call the API
├── test-local-storage.js     # tests for local storage
├── test-performance.js       # tests for deduplication verification
└── test-client.js            # tests for the connection

I had heavy LLM help in defining how I'd break things apart and the best practices for storing the concerns across multiple files. But the big takeaway was I was doing 19 files worth of functionality in 3 files, so now it's much easier to make small, isolated changes and feel I'm having the maxium amount of impact with the least amount of consequences.

As mentioned above, the gas fees were too low, which means that I've made decx.press too effecient. I've added some multipliers so that it at least hits the gas fee minimum to be incorporated on-chain. However, I know that Sepolia, which is the testing environment I am using to test my functionality on, has much lower gas fees than the Ethereum mainnetgit . It will be something I'll keep my eye on once I deploy to production.

Last Week

Finish up the work on the pressing functionality, finding a consistent way to press content [CLI#3] (almost done with this)

Next Week

Merge in the pressing functionality [CLI#3]
Start building the storage functionality for pressed (& TBD released) content [CLI#4]

Blockers

None.

Reflections on Process

Things are moving much slower than they were at the beginning of the semester. All the decisions from the past are piling up and making each continued step harder and harder to move forward on. I read an article once that (I cannot find currently) that made the case that the last 20% of the work takes up 80% of the time, and I'm finding that to be true now. I do feel like the end is in sight, or at least a satisfactory stopping point with robust enough functionality, so I'll keep hacking away at the vines.

Weekly Project Update #10

BD Tinsley — Thu, 03 Apr 2025 16:10:10 GMT

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.

Weekly Project Update #9

BD Tinsley — Thu, 20 Mar 2025 20:01:25 GMT

Last Week

What I Said I'd Do

Initialize the CLI [CLI#1] and get the changes up for PR

Start work on integration with MetaMask so Ethereum wallet details can be managed in a secure place [CLI#2]

Next Week

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

Blockers

None.

Reflections on Process

Everything is clicking. It's spring break for my kids but not for this program, so this week's work was front-loaded and this update will be scant.

Weekly Project Update #8

BD Tinsley — Thu, 13 Mar 2025 17:25:25 GMT

Overview

Last week's accomplishments, which included building a suitable off-chain encryption scheme, had me very excited. However, I got some feedback from my team that things are moving fast for them. I spent time this last week breaking the accomplished work and remaining work into some milestones, so it's easier to get a top level look at the categories of tasks remaining. I'm not making these time-dependent, rather just a good way to get an easy look at the status of the vision.

I've also spent some time reflecting on what I've done thus far, what's left and how I feel about it all in a project update.

Last Week

What I Said I'd Do

Get #37 merged

Begin work on building out the CLI [PRESS#35].

Additional Accomplishments

Written & posted my Project Update
Broken tasks into a Roadmap where I can easily filter by Milestone
Wrote 11 new Proof of Concept tickets to categorize work for the CLI, including 6 high priority MVP tickets
Moved the CLI code to a separate repository

Next Week

Initialize the CLI [CLI#1] and get the changes up for PR
Start work on integration with MetaMask so Ethereum wallet details can be managed in a secure place [CLI#2]

Blockers

None.

Reflections on Process

This was a low week in code but a good pause to plan the back portion of the semester. It will be tight, but I know I can get this done by semester's end.

Weekly Project Update #7

BD Tinsley — Fri, 07 Mar 2025 16:10:07 GMT

Overview

After a few dark nights of the soul, I was able to work through how the encryption/decryption can work off-chain. It still has some flaws, but I think it's a good step to handle something not natively done on Ethereum.

The quick version: it will handle the pressing of content in a wrapper process command line interface (CLI). This will coordinate creating content on the block via a Solidity contract, the contract will emit an event that goes into its transaction log, the CLI process will listen for this event, read the logs and encrypt the data along with it's unique path to each item on the blockchain and produce a final hash representation of all this work. The final hash produced will be the unique fingerprint of the entire content and when it's time to decrypt, the final hash will be used with the sender's private key and it will be able to trace through the block paths to reconstruct the original content in order.

The main flaws in this implementation are:

Actual The sender's private key must be passed around to decrypt. In the Additional Accomplishments section below, I've outlined a potential workaround for this. To sum it up, a Meta-Agreement Layer should be built to grant access, and its private key should be used to decrypt, not the Creator's private key.
Potential If the Ethereum network is moving slowly, the delay may cause the off-chain solution to hang or never complete. I'm not sure how to test this, but it's a bridge that will be built when the chasm is discovered.
Actual If the final hash is lost, the content is lost.

A quick comparison of synthetic gas fees:

┌─────────┬──────────────────────────────────────┬──────────────┬───────────┬───────────┐
│ (index) │              Operation               │  Gas price   │  Gas fee  │  In USD   │
├─────────┼──────────────────────────────────────┼──────────────┼───────────┼───────────┤
│    0    │  'novel hashing of "Hello, world!"'  │ '1016994671' │ '1143597' │ '$2.6248' │

In the above, prior to any attempt at encryption you can see the fees associated with pressing the phrase "Hello, world!", assuming none of the characters or pairs of hashes exist, cost about $2.62.

│    0    │  'novel hashing of "Hello, world!"'  │ '1017446225' │ '4705166' │ '$10.7920' │

Above is from my dummy encryption encryption venture last week, where I roughed out where encryption may go in the flow of the contract, but did it all on-chain. Naturally, it's much more expensive due to the computing required by the sender. You can see it's over 4 times as costly to press the same "Hello, world!" phrase, assuming none of the characters or pairs of hashes exist.

│    0    │  'novel hashing of "Hello, world!"'  │ '1017446225' │ '1713408' │ '$3.8680' │

Finally, in my off-chain encryption implementation, the fees return to much closer to what they were initially. As you can see, it costs about a dollar more in USD costs, which is due to the extra event emitting happening in the contract in comparison to the first example, however a ton of computing is done off-chain so it saves the sender a good amount of money.

Last Week

What I Said I'd Do

Finish and merge in the refactoring of the HashRegistry contract to handle encrypted content ticket

Come up with an off-chain encryption solution and document it in a ticket #34

Iceboxed Priorities

Build out a method for retrieving the DecxDAG hash from the contract via an API endpoint and viewing the original string (3 weeks week ago)

Deploy the built contracts to a testnet (from 4 weeks ago)

Plan how the API will work, what endpoints and methods it will have, and which tools I should use to implement it (from 4 weeks ago)

Additional Accomplishments

Built out off-chain encryption solution (dEKS) and put it up for PR #37
Documented how dEKS works
Wrote a WIP ticket to idenfify access layer for decryption #36

Next Week

Get #37 merged
Begin work on building out the CLI #35. Additionally, this will encompass many of my iceboxed priorities.

Blockers

None.

Reflections on Process

I'm putting in more time to this than the 3 hours this class suggests. I'm definitely starting to feel the burn of it. It still feels very exciting and there's tons of unique things to think about and problems to solve, but I do wonder what will happen to my motivation if I get stuck in a big task for over a week and I can't figure it out. This project beckons me on a deeper level, but I wonder how I will feel about it at semester's end.

Mind Map: Feb 2025

BD Tinsley — Fri, 28 Feb 2025 16:31:00 GMT

In the past month, I did a little bit of thinking on this

The reason we are repulsed by snakes is they look the closest to any 3 dimensional creature moving in 4 dimensions. It's pushed me to do some thinking on interdimensionality and what a 3 dimensional being moving in 4 dimensions may look like to a 4 dimensional being that moves in 5 dimensions or vice versa. It's hard to comprehend a higher-level dimensional being we observe from our dimension. We understand the shape of the 3d world but if a 2 dimeninsional being saw us, as a cross-section of our bodies passing through a plane of existence, we would look frightening and nothing as we believe we look. Likewise, any 4 dimensional being, trapped in our understanding of time would be truly horrifying.

The shape of our entire life, from the moment we are born to the moment we die is our form in 4 dimensions, not the shape of our body now. When observed by a 4 dimensional being that moves in 5 dimensions, do we move or are we just stationary objects? Thinking back, the film Annihilation did a fascinating look at what a 4 dimensional being interacting with a 3 dimensional being may look like, and the resulting scene of the 4 dimensional being creating a 3 dimensional being to interact with another 3 dimensional being. Both clips spoilers.

Is dance, specifically circular dance (around a fire, maypole, etc), so universal to the human experience because it is a way to create loud, defined 4 dimensional patterns? Is the reason we are intrinsically drawn to dance because it's calling us from a higher dimension to be in communion with it? Is the secret to happiness and longevity dance because it's the only way 4 dimensional beings can understand and appreciate our lives?

Slow Reader

The Body Keeps The Score (2014) - Bessel Van Der Kolk

Stats

Started reading Nov 17, 2024
Finished reading Feb 13, 2025
Total days reading 88
Total pages 358
Pages per day avg 4.068

Why it took me so long

I thought it was going to be more about physical trauma, but ended up being emotional and psychological trauma. A good book that made me think about many things, seeing myself in some of the discussions, but definitely a harsh book with some disturbing accounts of trauma. It’s a hopeful book though!

Key Quote

"The greatest sources of our suffering are the lies we tell ourselves."

Fad Habits

I've been doing a ton of psoas stretches with a lacrosse ball. Lots of issues perhaps - leg length discrepancy, posture seems wrong, etc. Could it all just be due to one side psoas muscle is tighter than the other? If so, I love easy solutions. If not, maybe I should take a more deliberate look at it.

Good Buys

Acupressure pen: I'm a hard gainer, so I have to have lots of theories on why. Does posture and small muscle tightness close up the large muscles with tons of knots to prevent muscle growth? It can be hard to notice how skewed you are until you put Zoom on with flipped camera view to see yourself as others see you in real time. The brain filters all that out when seeing yourself in the mirror. I've been using the acupressure pen to really dig into those knots and I'm noticing legs are looser, almost to a degree where it seems weak in muscles around the joints. Am I putting those muscles to work for the first time or am I ruining my body?

Dreams Worth Following

I love dreams with songs. Some song formed in which the only words were “I got out from the waterfall” to a chord progression somewhere between Breakthespell and Sweet Jane with a tone closer to Sweet Jane and a seriousness closer to Breakthespell.

Link of the Month

Tips for mathematical handwriting

Album of the Month

Sunsetter (2022) - LEISURE

Key Song: Dipping & Diving

CliftonStrengths Evaluation and the Continuing Prophecy of Being Who a Test Says You Are

BD Tinsley — Wed, 26 Feb 2025 19:35:00 GMT

To better understand myself, I ended up taking the CliftonStrengths assessment. While I am wary of these personality/proclivity assessments, I find myself falling prey to them time and time again. My main issue with them is how you are feeling in any particular moment dictates how you perform, much like the Hungry Judge Effect. Instead of re-evaluating your outcomes over, say, 1 month or 1 year, and taking the averages to determine the "now" you versus the "persistent" you, it only captures one instance of your mental state and reflects that back to you as if that's always who you were and always who you will be. This in turn creates an internal bias in yourself where you always think you should or do act in certain situations based off what some uninvolved test that assumes no responsibility said about you. It's like the people who are into astrology and will throw in a "that's such a Cancer thing to say!" or "that's the Taurus in you!" to forever trap people in a web of expectation based on something that may or may not actually be an honest assessment of this person's true nature.

I went into this test with best intentions and quickly remembered why I don't like them - they throw a ton of questions at you, all covering the same ten-or-so topics over and over, until you are totally mentally exhausted from it. They also seem very easy to fake. For example, if I could convince myself that a certain outcome made me more desirable for whatever goal I had, it would not be difficult to reach that goal, or at least close to it. Either way, I tried to take it earnestly, but my fatigue and irritation set in, which may or may not have affected my outcome.

Ok, enough overthinking. My top 5 outcomes were: Strategic, Adaptability, Ideation, Relator, Connectedness. I don't necessarily think these are bad, and likely Strategic is one of my core competencies because I couldn't help but notice that the results mixed nouns (Adaptability, Ideation, Relator, Connectedness) with adjectives (Strategic). Also there are 2 actual words (Strategic, Adaptability) and 3 made up words that could easily have been replaced with a real word (Ideation -> Imagination, Relator -> Empathy, Connectedness -> Relatable). It may seem petty that I'd focus on that, but when I see things like this, I can't help but fixate on how underdeveloped the entire thing may be if something as simple as a correct grammar hasn't been managed correctly, especially for something that costs $60 to participate in.

My results fit into 2 categories of the 4 total: Strategic Thinking (Strategic, Ideation) and Relationship Building (Adaptability, Relator, Connectedness). I sound like a likeable guy, I think: probably pretty smart with some good ideas, but I can't help but think about the categories I don't have in my top 5 with Executing, or anywhere in my top 10 in Influencing. I read this as I'm an ideas guy that struggles to do the work and struggles to convince other people to do the work either. So where does this put me?

This brings me back to my above point about the internal bias. Do I let this bother me? Do I start seeing myself as someone who is trapped with his ideas, his desire to be around other people, but can't follow through or enlist help? What kind of career or life is there for me with that?

Or do I chalk it up to me just being in a certain mindset when I took the test and assume if I took it again in 3 months, I'd probably get a better result, that I may or may not be trying to game the test for?

Weekly Project Update #6

BD Tinsley — Wed, 26 Feb 2025 17:22:00 GMT

Overview

Without really having a plan for what I'm about to write, I can feel that I'm going to write a lot. The last few weeks have been somewhat murky in terms of where I thought I'd be and where I have to be. To sum it up, I was off in my initial project plan by thinking that hashing and encrypting did the same thing. Hashing is a one way function, meaning whatever you hash cannot be reversed to regenerate whatever is stored there, while encrypting is. Solidity, the language for building contracts on Ethereum, has built-in hashing, but not encryption. Encryption must be done off-chain.

A real quick note about "on-chain" vs "off-chain" in case you are unaware: the chain in this scenario means blockchain, and any operation done on-chain means the person, or sender, of the contract is paying for the computing as it is done on the Ethereum network as a gas fee. Because encryption algorithms cannot be run on-chain, it means I've got to come up with a solution to figure out where the computing needs to happen. Some ways people handle this is running some decentralized app (dApp) that integrates with the contract, or sometimes a centralized app running on AWS or Heroku. The ultimate goal of decx.press is to bypass any centralized application and building a dApp feels like it would be a big ticket item. So I am electing to build out a minimal CLI (always part of the project plan) to utilize free computing on the sender's machine to handle the encryption and decryption. Eventually we will need to shift to a dApp to handle this, but for the sake of this class, I'm going as minimal as I can.

You may have noticed I have 2 somewhat concurrent and circular issues to handle - building a CLI to handle the computing needed for encyption and an encryption algorithm to properly store the content. It sort of feels like a snake that's eating itself. Or, a better metaphor: chain that links to itself. What's the starting link? I've decided to move forward with the encryption first, in a solution I'm calling decx Encryption Key Service (dEKS), which will pass the encryptions generated back to the contract as it awaits to create the transaction in a batch, rather than having to recreate hashing algorithms off-chain or get the sender to sign off on every single hash created.

If you aren't following this, don't worry! I'm hanging on by the seat of my pants here and I'm supposed to be the guy with the plan. Hopefully next week's report will have a much clearer description of how this all works, due to me actually building the thing out and seeing how it works.

Last thing, I must mention that I got the encryption roughed out last week by throwing a dummy non-encryption encryption algorithm on the contract to prepare for integrating with a more substantial solution. As expected, fees were much higher due to the additional computing happening:

Before dummy encryption fees

┌─────────┬──────────────────────────────────────┬──────────────┬───────────┬───────────┐
│ (index) │              Operation               │  Gas price   │  Gas fee  │  In USD   │
├─────────┼──────────────────────────────────────┼──────────────┼───────────┼───────────┤
│    0    │  'novel hashing of "Hello, world!"'  │ '1519812028' │ '1038681' │ '$4.3171' │
│    1    │ 'hashing attempt of "Hello, world!"' │ '1459334849' │ '428272'  │ '$1.7092' │
└─────────┴──────────────────────────────────────┴──────────────┴───────────┴───────────┘

After dummy encryption fees

┌─────────┬──────────────────────────────────────┬──────────────┬───────────┬────────────┐
│ (index) │              Operation               │  Gas price   │  Gas fee  │   In USD   │
├─────────┼──────────────────────────────────────┼──────────────┼───────────┼────────────┤
│    0    │  'novel hashing of "Hello, world!"'  │ '1519812028' │ '4705166' │ '$19.0037' │
│    1    │ 'hashing attempt of "Hello, world!"' │ '1459334849' │ '428272'  │ '$1.7092'  │
└─────────┴──────────────────────────────────────┴──────────────┴───────────┴────────────┘

You can see the novel hashing of "Hello, world!" is almost 4.5 times as costly with the encryption, but once a novel hash is stored, reusing it costs pretty much exactly the same in both. My hope is that by moving the actual encryption onto the sender's machine and getting free computing with that, the fees go back down to what they originally were for the novel hashings. Let's see what actually happens next week!

Last Week

What I Said I'd Do

Finish and merge in the refactoring of the HashRegistry contract to handle encrypted content ticket

Come up with an off-chain encryption solution and document it in a ticket [#34] / Figure out off-chain encryption for the DecxDAG (same priority from 2 different weeks)

Iceboxed Priorities

Build out a method for retrieving the DecxDAG hash from the contract via an API endpoint and viewing the original string (2 weeks week ago)

Deploy the built contracts to a testnet (from 3 weeks ago)

Plan how the API will work, what endpoints and methods it will have, and which tools I should use to implement it (from 3 weeks ago)

Additional Accomplishments

Wrote out a few tickets:
- Update dependencies [#32]
- Emit a Novel Hashing score to denote the uniqueness of the string pressed [#28]
- Research and Add license [#30]
- Implement CLI for Pressing & Releasing Content [#35]

Next Week

Finish and merge in the refactoring of the HashRegistry contract to handle encrypted content ticket
Come up with an off-chain encryption solution and document it in a ticket

Blockers

I'm in the rough of it now. There's no blockers but I'm seeing threats from all sides.

Reflections on Process

I'll just mention working with the team here.

Carlos has requested to work on a ticket pertaining to keeping track of the uniqueness of the pressed content due to how many novel hashes are created [#28] and Noah took on the task to update dependencies with critical or high vulnerabilities [#32] off the backlog without telling anyone and already got it up for PR [#33]. Even though things are feeling shakier in terms of next steps, the fact that I don't feel alone is helping me stay on task.

Weekly Project Update #5

BD Tinsley — Thu, 20 Feb 2025 22:17:00 GMT

Overview

This last week was a sort of a pivot from my original project plan due to the need for some sort of encryption solution. I may come back to where I left off in a week or 2, but the encryption aspect of storing content should be solved, or much of what I'm doing is just moving forward without purpose. The team met on Sunday, I told them what I was thinking and wanted to do and they think it all sounds good, albeit we are all a little unsure how it will work altogether.

Last Week

What I Said I'd Do

Figure out off-chain encryption for the DecxDAG

Iceboxed Priorities

Build out a method for retrieving the DecxDAG hash from the contract via an API endpoint and viewing the original string (from last week)

Deploy the built contracts to a testnet (from 2 weeks ago)

Plan how the API will work, what endpoints and methods it will have, and which tools I should use to implement it (from 2 weeks ago)

Additional Accomplishments

Merged in the DecxDAG contract
Had a meeting with the team to discuss focusing on encryption, which is a pivot from my original project plan
Wrote several tickets for the next phase of work [#28, #29, #30] as well as some draft tickets covering gas savings and off-chain encryption.

Next Week

Finish and merge in the refactoring of the HashRegistry contract to handle encrypted content ticket
Come up with an off-chain encryption solution and document it in a ticket

Blockers

After moving toward the encryption decision from last week, the new path is before me, albeit a much unsteadier one than it used to be.

Reflections on Process

I think I'm going to have to be less ambitious about what I can accomplish in a week from now on. I'm limiting myself to 2 main items from here on out because of all the times I haven't quite gotten to what I wanted to do. I'm also adding an icebox section to show tasks that I set out to do and pivoted away from, but I intend to get back to in the near future.

Weekly Project Update #4

BD Tinsley — Thu, 13 Feb 2025 16:41:00 GMT

Overview

The big accomplishment is building out the DecxDAG logic to handle the process of converting a string into a single representative hash. The tests checked the fees for possible transactions and it was fun and a relief to see the results were not astronomical.

From the test suite:

$npm run test


  DecxDAG
    Deployment
      ✔ Should deploy successfully
    Storage and Lookup
      ✔ should reject empty strings
      ✔ should store the same data for the same string in different transactions
      ✔ should store mixed multi-byte and single-byte characters
    Gas Optimization
┌─────────┬──────────────────────────────────────┬──────────────┬───────────┬───────────┐
│ (index) │              Operation               │  Gas price   │  Gas fee  │  In USD   │
├─────────┼──────────────────────────────────────┼──────────────┼───────────┼───────────┤
│    0    │  'novel hashing of "Hello, world!"'  │ '1519812028' │ '1038681' │ '$4.3171' │
│    1    │ 'hashing attempt of "Hello, world!"' │ '1459334849' │ '428272'  │ '$1.7092' │
│    2    │ 'hashing attempt of "hello, world!"' │ '1403557329' │ '479370'  │ '$1.8400' │
└─────────┴──────────────────────────────────────┴──────────────┴───────────┴───────────┘
      ✔ Should optimize gas usage by avoiding duplicate hashing
┌─────────┬──────────────────────────────────────────────────────────────────────┬──────────────┬───────────┬────────────┐
│ (index) │                              Operation                               │  Gas price   │  Gas fee  │   In USD   │
├─────────┼──────────────────────────────────────────────────────────────────────┼──────────────┼───────────┼────────────┤
│    0    │ 'novel hashing of "JUMPY DWARF FOXES BLITZ QUICKLY IN A NIGHT VEX!"' │ '1519812028' │ '3061503' │ '$12.7245' │
│    1    │ 'novel hashing of "jumpy dwarf foxes blitz quickly in a night vex."' │ '1468097242' │ '3737810' │ '$15.0068' │
│    2    │           'novel hashing of "INKLY KLARF JUICY QUIG VIC!"'           │ '1424165575' │ '1145214' │ '$4.4603'  │
│    3    │           'novel hashing of "inkly klarf juicy quig vic."'           │ '1375192882' │ '1043683' │ '$3.9251'  │
│    4    │       'novel hashing of "WOOO!!! LETS GO!!!! MAHOMES BABY!!"'        │ '1331556959' │ '1797339' │ '$6.5449'  │
└─────────┴──────────────────────────────────────────────────────────────────────┴──────────────┴───────────┴────────────┘
      ✔ should optimize gas usage by avoiding duplicate hashing for longer strings
┌─────────┬──────────────────────────────────────────────────────────────────┬──────────────┬────────────┬────────────┐
│ (index) │                            Operation                             │  Gas price   │  Gas fee   │   In USD   │
├─────────┼──────────────────────────────────────────────────────────────────┼──────────────┼────────────┼────────────┤
│    0    │ 'novel hashing of 555 characters from "The Old Man and the Sea"' │ '1519812028' │ '17413057' │ '$72.3737' │
└─────────┴──────────────────────────────────────────────────────────────────┴──────────────┴────────────┴────────────┘
      ✔ should optimize gas when storing extremely long strings

It works by taking a string, converting it into a character array, while ensuring that single-byte ('o') and multi-byte ('ö', 'ợ', '🅾️') characters are all handled correctly. Then it converts each character into a hash and then goes through the resulting pairs of hashes, converting them into a single hash, which iteratively reduces the hashes until there is only one. I diagrammed this Merkle Tree reduction, if you wanted to take a peek. The final hash is then stored in the DecxDAG contract and is the representation for the string.

In the above output, you can see the novel and replicative hashing attempts of certain strings and the gas fees associated with each. In the first table, the novel hashing attempt of "Hello, world!" means that none of the characters or pairs of hashes exist and must be computed. The replicative hashing attempt of "Hello, world!" and slightly modified "hello, world!" have much lower gas fees because they are able to reuse the existing hashes.

The sentence "JUMPY DWARF FOXES BLITZ QUICKLY IN A NIGHT VEX" contains all the characters in the English alphabet, so the following strings attempted can reuse the existing hashes. However, case sensitivity is not handled, so "jumpy dwarf foxes blitz quickly in a night vex." has a higher gas fee because it must compute all the hashes again, with a new puncuation mark. I don't exactly know why the fees for the upper case string are less than the lower case string in the jumpy dwarf strings but more in the inkly klarf strings.

Finally, just to test it out, I wanted to find where we run into the gas limit. I used an excerpt from "The Old Man and the Sea" which was able to handle the first 555 characters, but I ran into the limit somewhere above.

The fun thing to note is the more this is used and the more characters and hashes are added, the cheaper the computation becomes, which means strings will be able to get longer and longer.

Last Week

What I Said I'd Do

(carried over from 2 weeks ago) Refactor Solidity contracts for handling character-to-hash contracts and hashes-to-hash contracts

Ensure hashes-to-hash contract refactoring is complete #18

Merge any outstanding PRs

Build out the DecxDAG logic to handle the process of converting a string into a single representative hash #21

Deploy the built contracts to a testnet (check out my blockers below)

Plan how the API will work, what endpoints and methods it will have, and which tools I should use to implement it (related to the above)

Additional Accomplishments

Added an RSS feed to this site
Built in some basic formatting guidelines and enforcement for the codebase, using Prettier for formatting and Husky for pre-commit hooks.
Participated in Open Hours and PR Monday

Next Week

Figure out off-chain encryption for the DecxDAG
Build out a method for retrieving the DecxDAG hash from the contract via an API endpoint and viewing the original string

Blockers

Deploying to a testnet seems more complicated or expensive than I anticipated. I need to do some more research on the topic and get it out there so I can move forward.

In building out the original implementation of the DecxDAG, which hashes characters and paired hashes into a single hash, I've relized what I actually wanted to do was encrypt the characters and paired representations into a single encrypted hash. Looking into this, Solidity doesn't support encryption on-chain, so I will need to do some research on how to do this off-chain and then store the encrypted hash on-chain so it can be used as a means to exchange data. I think I can move forward with the current implementation (hashing, not encrypting), but it won't be the vision of decx.press at all. This is more of a philosophical blocker.

Reflections on Process

Last week both the PR Monday and Open Hours went well and the team took them seriously.

Weekly Project Update #3

BD Tinsley — Wed, 05 Feb 2025 21:17:00 GMT

Overview

I've spent a considerable amount of time this week ensuring that I can relate to the team members on the project and ensure I'm setting them up for success when they want to work on the project. I was able to finally put fingers to code and pair with Noah and Carlos to refactor the Character2Hash and HashRegistry contracts. I've also set up a few recurring events to help the team find an optimal flow despite all of our busy schedules.

Last Week

What I Said I'd Do

Refactor Solidity contracts for handling character-to-hash contracts and hashes-to-hash contracts (hashes-to-hash contract refactoring is not yet implemented)

Integrate a Hash Registry to handle deduplication across units

Add a Technical Architecture section to the wiki, with a basic "Glossary of Terms" and "Technical Decisions" sub-sections

Attend the Slambox talk

Additional Accomplishments

Added a Working on decx.press section to the wiki
Added a Git Flow Guidelines section to the wiki
Paired with team members (Noah & Carlos) to refactor the Character2Hash and HashRegistry contracts #17
Better incorporated team members into the project (Carlos), allowing him to take specific refactoring task for hashes-to-hash contracts #18
Set up a few recurring terminal events over the next month to help the team have more opportunities to work together and review each other's code:
- PR Mondays: Every Monday, team members will commit to reviewing any open PRs (Feb 10th, Feb 17th, Feb 24th, Mar 3rd)
- Open Hours: Every Friday, we will have an open Zoom call to chat about the project, pair program, or have unstructured conversations (Feb 7th, Feb 14th, Feb 21st, Feb 28th)
- First Sunday Retrospective: In place of our usual Sunday team call, we will have a retrospective on the first Sunday of the month to reflect on the process of the past month and keep things that are working and drop things that are not. (March 2nd)

Next Week

Ensure hashes-to-hash contract refactoring is complete #18
Merge any outstanding PRs
Build out the DecxDAG logic to handle the process of converting a string into a single representative hash #21
Deploy the built contracts to a testnet
Plan how the API will work, what endpoints and methods it will have, and which tools I should use to implement it

Blockers

I'm happy Carlos took on the hashes-to-hash contract refactoring and trusting him to accomplish the task. Getting more members involved in the project is great, but I anticipate it will cause some initial slowdowns. In the long run, I know it will pay off.

Reflections on Process

I'm curious to see how the events I set up will go. I think they will help the team get more comfortable with the project and each other. But I'm also aware that I need to be careful not to overwhelm the team with too many events. This is why I'm only committing a trial phase of 4 events and then automatically ending them by default, that way they can die quietly versus needing a conversation.

Weekly Project Update #2

BD Tinsley — Wed, 29 Jan 2025 20:01:00 GMT

Overview

The project proposal for decx.press was a big step towards creating a plan for the semester. It was a way to set clear goals for myself and to communicate with the decx.press team about what I need from them. They were very helpful in reviewing my proposal and providing feedback. We also discussed that it would be helpful to have a knowledge repository for the project. It's something I won't let creep the scope of the project, but it will be important as a first pass of documentation, motivation and best practices for the project.

Last Week

What I Said I'd Do

Create and post my project proposal

Review at least 2 classmates' project proposals

Share my project proposal with the decx.press team and articulate what I need from them

Additional Accomplishments

Made necessary edits and submitted my project proposal
Created an outline for the decx.press project wiki
Merged all open PRs into main on decx.press

Next Week

Refactor Solidity contracts for handling character-to-hash contracts and hashes-to-hash contracts
Integrate a Hash Registry to handle deduplication across units
Add a "Technical Architecture" section to the wiki, with a basic "Glossary of Terms" and "Technical Decisions" sub-sections
Attend the Slambox talk

Blockers

None! Let's get going.

Reflections on Process

This week I added a What I Said I'd Do subsection to my Last Week section as a way to remind myself if I'm accomplishing the things I said I'd do. I'd like to continue this practice for the rest of the semester. Otherwise, this week was still a lot of planning and not a lot of actual working. Next week, I'll have a better idea if the plan I set for myself is realistic and if there are changes to the process I need to make.

Weekly Project Update #1

BD Tinsley — Wed, 22 Jan 2025 17:14:00 GMT

Overview

Last week, I met with Prof. Guinn and other members of the class in CU's CSPB 3112 Professional Development course to discuss our prospective projects. I discussed the history and intention of decx.press as well as work done thus far. One of the main takeaways from the meeting is that given what the goals of decx.press are, it may be difficult to isolate the scope of what I can get done in the next 14 weeks. Prof. Guinn mentioned that this is a project that could worked on for years, so making sure I set clear milestones in the project proposal for myself will be important.

Last Week

Met with Prof. Guinn and other members of the class to discuss our projects
Diagrammed a Merkle Tree reduction algorithm for storing content

Next Week

Create and post my project proposal
Review at least 2 classmates' project proposals
Share my project proposal with the decx.press team and articulate what I need from them

Blockers

As decx.press is a team project, the main challenge I'm facing is getting everyone to contribute to the project, even in minor ways like reviewing PRs or showing up to meetings consistently. But these are minor issues, and I know that this is an issue that can be solved with my own communication and organization skills. I think a way to solve this is to show the team what I hope to accomplish once I've created my project proposal and be clear about what they can do to help me.

Reflections on Process

It's too early for me to have a good sense of how to speak to this. I think once I've created a map for the semester in the project proposal, I'll easier be able to find a way to both reflect and improve my process. A big question mark I hope to solve is how to fold the decx.press team into my process. I'm optimistic that I'll be able to do this.