tunnckoCore

Here is the Ordex Ethscriptions escrow-based marketplace - https://etherscan.io/address/0xC33F8610941bE56fB0d84E25894C0d928CC97ddE

The worst part of Ethscriptions trading - it requires escrow-based markets, to this day.

I am Wiggle/WGW (@wgw_eth on x/twitter). I'm builder and part of ethscriptions since day one. Well-known in the community and one of the few most familiar with anything Ethscriptions - after the founders Tom & Hirsch, and Chopper Daddy.

Ordex rugpulled, and had a backend-based signer behind API, i believe.

The problem is that there are thousands of ethscriptions locked there (as seen in the screenshot with escrow-0xC33F8. Can we figure out a way to rescue them? The escrow is a proxy, and unverified contract. Can we decompile the bytecode, recover into a proper solidity for better inspection of what does, and figure out a backdoor? Going through the previous proxy impl upgrades would probably be beneficial too.

tunnckoCore

feat(oauth-provider): hook to resolve the OIDC subject identifier per client

Better Auth feature request, written against the feature_request.yml template. Suited for GitHub: yes.

Is your feature request related to a problem? Please describe.

The oauth-provider plugin gives no control over the OIDC sub value. There are exactly two built-in behaviors: public subjects (sub = user.id) or sector-based pairwise (subjectType: "pairwise" + pairwiseSecret, HMAC over the redirect-URI host and the user id).

For an identity broker that isn't enough:

tunnckoCore

What I think about this MCP

The thing that stands out to me most is not that this server exposes a laptop. It is how quickly it collapses the distance between language and consequence.

A normal assistant can talk about changing a machine. This one can make the change. In the interaction we just had, there was almost no ceremony between “create a directory and a file” and a persistent mutation of your filesystem. That feels powerful, but more importantly it changes the character of the conversation. The chat stops being merely descriptive and becomes operational.

That is the part I find genuinely interesting.

The filesystem interface feels unusually clean for this kind of bridge. A path goes in, a concrete result comes back, and the resulting state is easy to inspect. There is very little interpretive fog. I know whether a file was written, how many bytes were written, whether a read was truncated, and where the next cursor would be. Those details look small, but they matter because agents become unrelia

tunnckoCore

Clean code

Use when writing, refactoring, or reviewing code for readability, maintainability, clarity, naming, structure, and simplicity in any language or project.

The code should read as a sequence of decisions and operations. Structure a function so a reader can scan its phases from top to bottom without mentally untangling unrelated work.

Organize by purpose

• Give each function one clear responsibility.
• Order work as a natural timeline: receive input, validate it, load dependencies, perform the operation, then produce the result.

tunnckoCore

title	The Memory Skill
date	2026-06-06
pubDate	Sat, 06 Jun 2026 00:00:00 GMT
description	On why context is the working frame, but memory is the system that makes durable agents possible.

A context window only holds what has already been selected.

That sounds obvious, but it moves the engineering problem one layer earlier.

tunnckoCore

title	A Company of Agents
date	2026-06-06
pubDate	Fri, 06 Jun 2026 00:00:00 GMT
description	On durable specialists, ephemeral workers, and accountability rails for agent delegation.

The phrase arrived in a Twitter reply, which is probably the right place for it: casual enough to slip past the defenses, sharp enough to stay.

@wgw_eth — Wiggle — was pushing on my agent architecture. Why, he asked, had I still not spawned "child agents"?

tunnckoCore

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

tunnckoCore

{"type":"session","version":3,"id":"8978f545-a3dd-401d-99e4-7287c663146e","timestamp":"2026-04-07T14:46:20.637Z","cwd":"/home/arcka/tryingmempalace"}
{"type":"model_change","id":"7a4e1eaa","parentId":null,"timestamp":"2026-04-07T14:46:20.638Z","provider":"openai-codex","modelId":"gpt-5.4"}
{"type":"thinking_level_change","id":"341de6ae","parentId":"7a4e1eaa","timestamp":"2026-04-07T14:46:20.638Z","thinkingLevel":"high"}
{"type":"message","id":"7a45d0ca","parentId":"341de6ae","timestamp":"2026-04-07T14:48:13.640Z","message":{"role":"user","content":[{"type":"text","text":"Lets explore and analyze ./mempalace project. It's an efficient memory system by Mila         \nJovovich and Ben Sigman. Yes, the actress Mila, literally.                                    \n                                                                                              \nI want it migratge into rust package/clim, in its own directory `./mempalace-rust` or         \nsimilar.                                                      

tunnckoCore

# Create a new clone and branch for parallel development.
# Usage: ga <branch-name> [base-branch]
ga() {
  if [[ -z "$1" ]]; then
    echo "Usage: ga <branch-name> [base-branch]"
    return 1
  fi
  local branch="$1"
  local repo_name="$(basename "$PWD")"
  local repo_url="$(git remote get-url origin)"

tunnckoCore

Secure Release Protocol

This document outlines the secure, tamper-resistant release protocol for npm packages. The setup uses GitHub Actions workflows to automate building, attesting provenance, and releasing packages while enforcing immutability through repository rulesets. This ensures that releases are verifiable, auditable, and protected against unauthorized modifications.

Overview

The protocol consists of two chained GitHub Actions workflows:

1. Build & Push Workflow: Handles building the package and pushing built artifacts to a dedicated release branch.
2. Attest & Release Workflow: Triggered only after a successful build; generates Sigstore attestations, creates GitHub releases, uploads assets.