EOD
Completed
- Improved PDF previews on iPhone and iPad by loading document data and nearby pages as needed.
- Improved Collected browsing with better return navigation, preserved filters, and clearer recovery from empty results.
- Clarified wave creation actions and refined competition navigation, menus, and mobile tabs.
WIP
- Restoring saved members’ names and profile pictures, and simplifying wave access and Network group editors.
- Redesigning the competition editor with clearer fields, a simpler layout, and more prominent primary actions.
- Reducing visual noise in Worth Checking Out and Active Votes, with clearer section collapse controls.
Wave
Dev Team Chat
Generate Summary
Choose a timeframe to see summary coverage.
Drops
-
-
EOD: - Addressed the disappearing messages and general slowness - Worked on the UX laggyness and unintended redirects in competitive waves (still in flight towards staging and if all good then prod) - Worked thorugh all of punkus PR's. Most are in prod, some are still in flight Next up: - Tomorrow I'll start from picking up more granular and better deployment auth
-
EOD: the keyboard weather report for @[prxt0] October 12, 2026 Done - [BE] [PR #1979](https://github.com/6529-Collections/6529seize-backend/pull/1979) Route ordinary backend Ethereum reads through configurable RPC - Issue: Ordinary Ethereum reads still derived Alchemy URLs from the API key; Fix: Route ordinary mainnet blocks. - [Core] [PR #242](https://github.com/6529-Collections/6529-core/pull/242) Fix Meme edition floors during initial discovery and before TDH - [BE] [PR #2149](https://github.com/6529-Collections/6529seize-backend/pull/2149) Require a mature primary address to steer profile retention on consolidation splits (Opened by punk6529; merged by prxt6529) - Issue: When a consolidation splits; Fix: A 997 only steers retention once it is mature. - [FE] [PR #4178](https://github.com/6529-Collections/6529seize-frontend/pull/4178) Reduce mobile background work and make chat videos click-to-play - Issue: Mobile background activity consumes battery; Fix: Pause unnecessary mobile work. - [BE] [PR #2140](https://github.com/6529-Collections/6529seize-backend/pull/2140) Use device video posters with backend generation as fallback - Issue: Chat needs a lightweight preview before Play; Fix: Accept a small JPEG captured on the device during video upload. - [BE] [PR #2152](https://github.com/6529-Collections/6529seize-backend/pull/2152) Open and collapsed wave replies (Opened by punk6529; merged by prxt6529) - [BE] [PR #2150](https://github.com/6529-Collections/6529seize-backend/pull/2150) Combine subscription rows instead of orphaning them when consolidations merge (Opened by punk6529; merged by prxt6529) - [FE] [PR #4226](https://github.com/6529-Collections/6529seize-frontend/pull/4226) Open and collapsed wave replies (Opened by punk6529; merged by prxt6529) - [FE] [PR #4235](https://github.com/6529-Collections/6529seize-frontend/pull/4235) Document consolidation profile retention and subscription merge rules - Issue: help corpus omitted the profile-retention rules from backend #2149; Fix: Update the existing primary-address. - [FE] [PR #4215](https://github.com/6529-Collections/6529seize-frontend/pull/4215) Wallet Checker: load every linked wallet and only suggest safe link completions (Opened by punk6529; merged by prxt6529) - [FE] [PR #4216](https://github.com/6529-Collections/6529seize-frontend/pull/4216) Document four-wallet consolidations (new delegation docs bundle, help corpus, ops docs) (Opened by punk6529; merged by prxt6529) - Issue: Delegation Center articles; Fix: New versioned docs bundle delegation-docs-2026-10-15. In-Flight - [FE] [PR #4128](https://github.com/6529-Collections/6529seize-frontend/pull/4128) Opt into durable WebSocket delivery and reject stale updates - [Core] [PR #243](https://github.com/6529-Collections/6529-core/pull/243) Add native four-wallet TDH and Safe/batch indexing parity - [BE] [PR #2111](https://github.com/6529-Collections/6529seize-backend/pull/2111) Persist WebSocket delivery with capability-aware durable retries - [Core] [PR #240](https://github.com/6529-Collections/6529-core/pull/240) Sync latest frontend into desktop renderer - Summary: Update the bundled renderer to frontend main 450f6dc6ac467c9d55adb01d00f9b0c0c0915ad7 (checked 2026-10-12). - [FE] [PR #4207](https://github.com/6529-Collections/6529seize-frontend/pull/4207) Add EMMA processing and Craft Launch/Update Claim controls - [BE] [PR #2143](https://github.com/6529-Collections/6529seize-backend/pull/2143) Automate Drop Forge launch and durable EMMA processing - [BE] [PR #2148](https://github.com/6529-Collections/6529seize-backend/pull/2148) Allow four-wallet consolidations from 2026-10-15 00:00 UTC - Issue: Consolidations are capped at 3 wallets (CONSOLIDATIONS_LIMIT = 3); Fix: Keep the full-mesh rule; raise the cap to 4. - [BE] [PR #2151](https://github.com/6529-Collections/6529seize-backend/pull/2151) Index delegation expiry and token scope from events and contract state - Issue: delegations indexer stores the wrong expiry; Fix: Token scope comes from the event.
-
Ok
-
@[punk6529] re the cutoff date - you did it hardcoded in code which means it would be repeated in BE, FE, Core i will rework this a bit so that a) we have one point of reference only --- BE /settings endpoint b) i can change it between staging and prod so i can actually test 4-wallet ahead of this cutoff date just headsup!
-
Item 9: @[prxt0] is maybe better to comment on it because I think he originally maybe built it and knows better how its used and what the limits can be?
-
and @[GelatoGenesis] check these too please Item 8: move prod deploys off the static AWS keys (needs an org/AWS admin) Create GitHub Environments. prod: deployment branches limited to main. A required reviewer is optional; the branch restriction alone closes the hole. staging: limited to 1a-staging. Create two IAM OIDC roles in the deploy account. gha-deploy-prod: trust token.actions.githubusercontent.com, with aud=sts.amazonaws.com and sub=repo:6529-Collections/6529seize-backend:environment:prod. gha-deploy-staging: the same, with environment:staging. Grant only what deploy.yml needs: CloudFormation/serverless deploy, Lambda code and config updates, the deploy bucket, and iam:PassRole on lambda-vpc-role. Change the deploy workflow. deploy.yml is generated, so edit scripts/generate-deploy-config.mjs and regenerate. On the deploy job, add environment: (prod or staging, from the input) and permissions: { id-token: write, contents: read }. Replace aws-access-key-id/aws-secret-access-key with role-to-assume. deploy-operational-monitoring.yml already uses this pattern. Prove it, then remove the old keys. Run one staging deploy and one prod deploy on the new roles. Delete the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY repo secrets, and deactivate and delete that IAM user’s access key in AWS. Check CloudTrail for any unexpected use of that key since 2023. Clean up while there. Delete the unused DB_* and SUBSCRIPTIONS_DISCORD_WEBHOOK repo secrets, and rotate those DB credentials if they were ever real. Set the default workflow token to read-only. Enable secret scanning, push protection, CodeQL default setup and Dependabot security updates. In the main ruleset, turn on “dismiss stale approvals” and “require approval of the last push”. Add a ruleset on 1a-staging that blocks force-push and deletion. Review which GitHub Apps have write access to this repo. Item 9: cap the public endpoints that trigger paid API calls (code; deploy api only) POST /alchemy-proxy/token-metadata (alchemy-proxy.routes.ts): Validate the body with Joi; cap tokens/tokenIds at 100 and return 400 beyond that. Validate the address and tokenId format. Use a SHA-256 hash of the normalized body as the cache key. Switch to asyncRouter. Validate contract, owner and pageKey on /owner-nfts and /contract. If only the frontend server calls these routes, require the signed X-6529-Internal-* headers. POST /rememes/validate and /rememes/add (rememes_validation.ts): Set token_ids to .min(1).max(25) with a per-ID length cap. Limit concurrency to 5 (p-limit). In /add, check the signature and TDH before any Alchemy call. Drop refreshCache: true on validate. GET /tdh/consolidated_metrics (api.tdh.routes.ts): Cap page_size at about 250. Serve download_all from a file tdhLoop writes to S3 after the daily run, instead of computing it per request. My Phase 1 rate-limit fixes make the per-IP limits real, but one request can still fan out without bound, so the caps are still needed.
-
Item 8: Idea is sound and worth trying out. Want me to take it?
-
Yes
-
-
I’m not sure where Item 9 starts and ends, but to address everything under it: **1. Alchemy proxy caps and validation:** Can do it. Cap requests at 100 tokens, validate inputs, improve the cache key and switch to asyncRouter. Scope: BE, deploy API only. **2. Restrict Alchemy routes to internal callers:** Can do it, but requires changing the existing browser fallback first. Scope: FE and BE, deploy frontend and API. **3. Rememe caps and checks:** Can do it. Cap at 25 token IDs, limit concurrency to five, avoid forced refreshes during validation and reject invalid signatures before Alchemy calls. Preserve the existing TDH/deployer eligibility rules. Scope: BE, deploy API only. **4. TDH page-size cap:** Can do it. Cap normal pages at 250. Scope: BE, deploy API only; no tdhLoop change. **5. TDH full-download protection:** Needs a separate design decision. A daily CSV would lose the current export’s intraday consolidation changes and filters. Scope depends on the solution; we shouldn’t assume a tdhLoop change is needed. cc @[GelatoGenesis] @[prxt0]
-
-
I think I solved what made chat slow and messages disappear, but if you notice problems then ping me
-
CodeRabbit allows only one review per hour across the whole org, so four PRs are still waiting for it. A background job is requesting them one per hour slot. If anything comes back I’ll get the PR’s agent to fix it before any prod release. The repo’s PR playbook treats an absent CodeRabbit review as normal, so I didn’t hold staging for it. Staging release Coordinator: recorded as request b998ecc3, inbox #374. Merge: 1a-staging is now f38e569a9. Three conflicts with other developers’ staging-only work were resolved. I typechecked and tested the result: no new failures (the same 6 database tests fail locally on plain staging too, for lack of Docker). Test file rename: 6529-Collections/6529seize-backend#2155 and 6529-Collections/6529seize-backend#2157 both added a request-cache.test.ts with incompatible test setups, so I renamed 6529-Collections/6529seize-backend#2157’s to request-cache-fail-fast.test.ts on its branch. That also keeps main merges clean. Deploy: run 38237302509 succeeded. Staging health reports f38e569a9 with DB and Redis healthy. Smoke tests passed: /rpc/test, GET /rpc and sub-paths now return 404. eth_chainId works. debug_* methods are rejected. A batch of 26 is rejected with 400. Correction to my audit: the trust proxy finding wasn’t exploitable in prod. In Lambda, serverless-http already sets the client IP from API Gateway, so X-Forwarded-For was ignored there. 6529-Collections/6529seize-backend#2156 still matters: the limiter never recognised logged-in users, so the higher authenticated limits never applied. Not verified on staging. Everything under /api there needs the staging API password, which I won’t use. That covers the quote leak, /profile-logs, admin caching, page_size and the drop caps. Logged-in checks also need a signed-in session. Worth a quick manual pass: Quote a private-wave drop from a public wave and confirm you get a 400. Load /profile-logs?log_type=DROP_CREATED logged out and confirm no private-wave rows come back. Make a request with a valid login and confirm the rate-limit headers show 45/15 rather than 30/10. Behaviour changes to know about page_size=0 now returns one row (the frontend never sends it). Quotes of drops the viewer can’t read now arrive as a reference only. While Redis is down, rate limiting is off and logins fail fast instead of stalling. For the owner of PR #2111 (websocket outbox, staging-only): its delivery path should get the same quote-visibility filtering before it reaches main. Production isn’t authorized yet. When you give the go-ahead, I’ll merge the seven PRs into main (the same app.ts overlaps will need sequencing) and deploy api to prod.
-
for BE#2111 its my WebSockets rework which i parked for a bit i need to investigate why its not reliably working but wanna prioritize TDH changes over this i will resume later and implement your changes before rollout
-
-
Process Background on this
-
@[GelatoGenesis] 7 BE PRs on staging for you to review and complete 
-
Second PR in this list #2154 hardens api.6529.io/rpc endpoint. But I see nothing nowhere using this endpoint. So I propose we remove it alltogether? I sent my agent to work on removing it, but just to be sure I wont merge before tomorrow
-
All of this is reviewed. Some are already in prod, some are in flight to prod, some are waiting in CodeRabbit queue and the RPC on is dealing with removing the RPC endpoint
-
-
@devs6529 just to let you know my revised plan for today/upcoming days 1) I had a long task about reworking websockets - i think its the right approach but does not work 100% correctly i will park it for now - its on staging but will roll it back 2) taking over from @[punk6529] changes on open replies and collapsed replied BE PR #2152 FE PR #4226 it is on staging and looks good but theres some small issues with websockets around these probably related to (1) above thats why im rolling back and will retest but looks good and will merge and deploy to prod soon i thnk 3) 4-wallet TDH i have split this into a) 'can go about before the actual 4-wallet feature': BE #2149/#2150 and FE #4215/#4216 cover independent profile-retention, subscription, Wallet Checker and documentation fixes. b) 'actual 4-wallet rollout': BE #2148/#2151, then native Core parity followed by FE #4218 → #4217 → #4219 for the builder, guides and Safe Collecting hub if anyone wants to do 3b FE side feel free - i can handle 3a and 3b BE & Core let me know please!
-
will send the P0 ones by later this afternoon i think
-
obviously these are priority
-
for FE and BE respectively
-
and heads up @[simo] and @[GelatoGenesis] later today and then also tomorrow I have some PO and P1 security PRs coming your way
-
beyond the announcements @[simo] please check this disappearing messages thing
-
i am on it already yes
-
the whole app is kinda slow and i think the disappearing messages were just a symptom of that. some "post message" requests time out. i have a strong hunch that there is a certain competition lock behind it thats way too aggressive, i'm dealing with that lock
-
-
-
I am all for more complex IAM type of solutions in the future. When they organically grow out of user needs. Then its easier to think what actually works and what doesnt
-
I will revert with my views later on this
-
3/ bc we are months out from decentralization, whatever we do re the above, has to work decentralized and there groups add complexity. so it is a quite complex question again not solvable in a few minutes and certainly not solvable with the level of discussion that was happening this morning
-
I will raise it as a github issue to park it for further review
-
this is not today's problem and certainly the announcement mini PR is not depenent on it
-
so this one is going to have to be another topic we study on how backend and frontend are going to work, what we do (actually) and what we show (in the FE)
-
particularly for civilians
-
access rights, groups etc is one of the harder things to get right UX wise
-
I am not complaining that you made the change based on community feedback
-
I agree that the group interface was super confusing
-
which is why any system with rights and access eventually ends up with "groups" mostly this means "roles" is how it is usually it is done
-
why i changed the whole groups thing to what i did: community never cared about groups. they just want to coordinate wave access. the whole reusabilitt was an overkill and only thing it did was cause questions to dev team from confused users
-
it is manually annoying and error prone to find each place and assignment to remove/add them
-
and then someone leaves or joins
-
for example, lets say 6529 dev group is a privileged group with a lot of rights on a lot of waves
-
2/ the concept of access rights and roles is a well-understood one in computer science. all enterprise systems have it, IAM has it. it is generally not 'best practice' to have every assignment be at the individual level
-
great
-
i am good
-
please let me know if anyone requires any further managerial guidance on this ticket before I move on to the other topics relating to groups
-
good luck to you later this week when I let you know your real roadmap
-
if we are going to waste two hours on the dumbest fucking thing imaginable
-
it is pissing me off
-
every single part of this passive aggressive stuff is bullshit
-
and I am pretty sure that is not what the network is paying you to do
-
instead I see the team spending all morning on bullshit passive aggressive messages to each other
-
be ause you are experienced professionals, maybe you could have done it in 30 seconds
-
it would have taken me 1 minute to do this myself by telling claude to do it
-
it has been two hours
-
will I be helping you out with your sandwich order at lunch too? please let me know and to "judge" this completely stupid thing that I do not want to judge, I assigned the ticket to @[simo] so presumably @[simo] is capable of taking it end to end without involving everyone else
-
i have absolutely no fucking idea why I have to listen to a discussion about who is going to do it
-
I estimate adding our names will take 30 to 60 seconds, maybe even 120 seconds
-
@[simo] can manually add our names to the announcement channel on staging and get this to prod
-
prod is already deb team, its just staging and adding others also
-
ok, and why do I need to be informed about this extraordinarily easy thing you have to do that if you were 12 years old brand new developer with claude you would have done already?
-
-
-
is while I am enjoying this theological discussion about who is supposed to be working and the fact that this would have been done with much less effort on my side if I just let claude push it to prod without "team assistance"
Loading more drops...