🛠️ DevLog – Rough E2E for Offchain Storage v3 on Testnet0 After patching the two gaps we found earlier and polishing the dashboard a bit more for v3 offchain storage, we ran a rough E2E test on testnet0. 🔹 What worked in this pass - Router was able to store payloads through the new v3 offchain/configurable S3 path. - Miner was able to read that v3 offchain data and continue the normal flow. - Dashboard was able to recognize and present the v3 task/result data correctly. 🔹 Current scope - This is still a very rough E2E pass, but at least the main v3 path is working on testnet0. - For now, configurable offchain storage is still targeted at dedicated-node sessions only. - Ephemeral-node support is a separate problem because of the added security / permission concerns around storage access, so we’ll revisit that later. 🔹 What’s next - Push this forward on testnet0 and keep iterating. - Then next week, we’ll also try testing this together with task-level encryption scope. #Cortensor #DevLog #OffchainStorage #DataOwnership #DedicatedNodes #DePIN

🛠️ DevLog – Data Ownership Progress: Rough Router/Miner Changes Next We’ll be pushing the rough router miner code changes for configurable offchain data paths later today and build/push them to dev-stable for now. 🔹 What this means - This is the next step in the broader data ownership direction: - privacy / encryption on one side - operator-controlled offchain storage on the other - With this in place, the current MVP privacy data ownership feature set is mostly there for now. 🔹 What’s still the main gap - The bigger remaining issue is still inference quality, especially on the ephemeral side. - Privacy itself is behaving roughly as intended, but inference quality / SLA is still the harder gap to close for real user flows. 🔹 What comes next - We’ll keep assessing that inference-quality gap during this phase. - Then try to address/fill more of it in the next phase, likely through the quality/SLA ideas we’ve mentioned before: - better filtering - health/prover-style checks - and stronger routing decisions closer to real task assignment So the short version is: privacy data ownership MVP is getting set, and inference quality remains the main next gap to solve. #Cortensor #DevLog #Privacy #DataOwnership #OffchainStorage #EncryptedInference #DePIN

🛠️ DevLog – Follow-Up: Rough Offchain Storage Changes Moving Into Code Follow-up on the configurable offchain storage idea: we’ve now gone a bit beyond pure design and have been playing with rough mock code / rough implementation paths around it. 🔹 What’s happening now - We’ve already explored the main router/miner code paths enough to have a workable rough design. - Based on that, we’ll try to start adding some of these changes today and test them locally while the current privacy tests are still ongoing. 🔹 What this work is about - Letting offchain payload storage become more router/operator configurable instead of assuming one default storage path. - Keeping the current default behavior as fallback, while making room for operator-specific storage config later. 🔹 Why this matters - This sits closely next to the broader privacy/data-ownership direction: - encryption is one side - where the encrypted data is stored is the other side - So while privacy tests continue, this becomes one of the next practical follow-up items to start shaping in code as well. Still rough and early, but the design is clear enough now that it makes sense to begin local experimentation. #Cortensor #DevLog #OffchainStorage #Privacy #EncryptedInference #DePIN

🛠️ DevLog – Rough Design for Configurable Offchain Data per Router We now have a rough design picture for making offchain data storage configurable per router/operator. 🔹 What’s clearer now - We’ve identified the main places that need to change in both the router and miner code paths so offchain payloads can use operator-specific storage instead of one default path. - This gives us a workable base for supporting per-router / per-operator offchain storage. 🔹 What we’re thinking through next - Edge cases and UX around configuration changes, for example: - what happens if the storage config changes later - what happens if the old storage path no longer exists or is no longer reachable - These are important because storage configuration becomes part of the real data lifecycle, not just a simple env toggle. 🔹 Current direction - For now, the storage config would live in env/config. - Longer term, similar to PrivacySettingData, some of this information could move on-chain in a more immutable form so session/storage behavior is easier to reason about. This is still rough design work, but at least we now have a clearer view of the code paths and the next design questions to solve. #Cortensor #DevLog #OffchainStorage #Privacy #EncryptedInference #DePIN

🛠️ DevLog – PR: Task-Level Encryption Scope Support for Private Sessions Pushed a PR for the next privacy step: task-level encryption scope for private session payloads, while keeping the current session-level flow as the default. github.com/cortensor/install… 🔹 What this PR adds - Backend support for task-level encryption scope without changing the default session-level behavior. - PrivacySettingData tracking for task-scope settings, with fresh-session-only enablement. - Router-side payload encryption updates so offchain v2 requests can derive/store the correct task-scoped metadata. - Miner-side decrypt/result flow kept aligned with the encrypted payload’s scope metadata. - Backward compatibility preserved by falling back to session-scope behavior when older contracts do not expose the new task-scope getter. 🔹 Why it matters - Session-scope privacy remains the main default path. - This PR adds the stronger task-by-task isolation layer so we can test it next once the current privacy flow is stable. #Cortensor #DevLog #Privacy #EncryptedInference #TaskScope #DePIN

🛠️ DevLog – Task-Level Encryption Scope: Rough Support Added We’ve made the rough adjustments needed on both PrivacySettingData module and the router node to support task-level encryption scope more fully. 🔹 What’s done - Rough code is in for task-scoped privacy settings / key path support. - We’ve already deployed this to testnet0 to make sure it doesn’t introduce regression against the current privacy flow. 🔹 Current stance - We’re not actively iterating or testing task-scope yet. - Session-level encryption is still the main path, and we want that flow to be stable first before opening another test track. 🔹 What’s next - Finish the remaining session-level privacy tests this week. - Then try to start task-level encryption tests next week. - Dashboard work is still needed as part of that path as well. So the rough support is there now, but the main priority remains: stabilize session-scope first, then exercise task-scope next. #Cortensor #DevLog #Privacy #EncryptedInference #TaskScope #DePIN

🛠️ DevLog – Third SLA Filter Idea: Inference Health Prover Following the earlier SLA / ephemeral node quality notes, one idea we’re now shaping more clearly is a third SLA filter on top of node capacity and user-task statistics. 🔹 Rough design idea - Add an inference health prover that periodically sends sample requests through the full E2E path on selected nodes. - Record the outcome in a separate table/module: - success / failure - latency / timeout behavior - last checked time - recent failure streaks or degradation signals 🔹 Why this matters - Some nodes look fine by raw capacity, but degrade over time or struggle on first-run / warm-up for newer models. - A health-prover table gives us a more direct signal of real inference quality, not just theoretical capability. - This could become a third router-side SLA filter during node selection, especially for ephemeral pools. 🔹 Longer-term use - The same table could also feed into: - node performance pages - reward logic / performance filtering - better visibility into which nodes are actually healthy for user-facing workloads Still a rough idea, but it feels like an important missing layer if we want node selection to reflect actual inference reliability, not just specs and historical task stats. #Cortensor #DevLog #SLA #Inference #NodeOps #DePIN

🛠️ DevLog – Task-Scoped Encryption Prep in Progress Follow-up on the privacy scope note: while we’re still running tests and regression on the current session-scoped encryption flow, we’ve also prepared the next step for task-scoped encryption. 🔹 What’s been done - No full wiring yet, but the rough code/changes on the PrivacySettingData module are already in place for task-level encryption settings / tracking. - This is meant to give router and miner enough signal later to understand which scope key path should be used for a given task. 🔹 Why this matters - Session-scoped encryption is still the main path we’re testing right now. - Task-scoped encryption is the next layer, where each task uses its own deterministic key for stronger isolation. 🔹 What’s next - We’ll deploy these PrivacySettingData changes to testnet0 later this week once the remaining session-scope tests and regressions are done. - If the current session-level flow looks stable enough, then task-scoped encryption will be the next path we exercise more directly. #Cortensor #DevLog #Privacy #EncryptedInference #TaskScope #DePIN

🛠️ DevLog – Privacy Tests on Sessions 103/104, RPC Infra Under Review Basic tests and stress tests are still running on session 103 and 104. 🔹 Current status - So far, we’re not seeing obvious regression yet on the backend / miner / router side for the current privacy flows. - At the same time, we’re seeing intermittent RPC / infrastructure instability, so the environment may not be fully stable right now. 🔹 What we’re seeing on the infra side - The main error appearing on and off across nodes is: - General web3 exception: {'code': -32000, 'message': 'context deadline exceeded'} - Since this is showing up across nodes intermittently, it currently looks more like an RPC / infrastructure issue than a privacy-flow-specific regression. 🔹 What we’re doing next - We’ll check the RPC / infrastructure side further first before pushing harder on the privacy tests. - Once that looks stable, we’ll continue the current regression and E2E passes on sessions 103 / 104. 🔹 Dashboard / UX follow-up - We’ll also make some dashboard/UI adjustments later today to fill a few gaps, including clearer indication of whether displayed content is encrypted or not, even for private sessions. #Cortensor #DevLog #Privacy #EncryptedInference #RPC #Testnet1a #DedicatedNodes #EphemeralNodes #DePIN

🛠️ DevLog – Privacy Scope: Session Default, Task Scope Also Available A quick clarification on the current privacy / encryption scope. 🔹 Current state - The privacy flow today defaults to session-scoped encryption. - But task-scoped encryption is also already supported and rolled out: - keys can be derived from session_id task_id seed - giving each task its own deterministic encryption key 🔹 Why this matters - Session scope is simpler and is the main path we’ve been exercising in current privacy v1.0 tests. - Task scope gives stronger isolation, since each task uses a separate key instead of sharing one across the full session. 🔹 What’s next - Even though task-scoped encryption is already in the system, it has not yet been tested end-to-end as deeply as the current privacy 1.0 session-scoped flow. - So after we close the main gaps on the current privacy flow, we’ll also spend time validating the task-scoped path more fully. So the short version is: session scope is the current primary test path, but task-scoped encryption is already there and will be exercised more once the broader privacy flow is stabilized. #Cortensor #DevLog #Privacy #EncryptedInference #DePIN

🛠️ DevLog – Starting Privacy E2E / Integration Tests on Testnet1a We’re now kicking off the next round of privacy feature tests on testnet1a, including basic checks, regression passes, and then fuller E2E coverage. 🔹 Test scope - Both dedicated and ephemeral private-session flows are ready enough to begin this round of testing. - We’ll use router1-t1a.cortensor.app as the main endpoint for the first basic passes. 🔹 Initial sessions - Dedicated session: dashboard-testnet1a.cortenso… - Ephemeral session: dashboard-testnet1a.cortenso… 🔹 Plan for this week - Start with basic flow regression checks on both sessions. - Then move into more focused privacy-path testing. - After that, push into full E2E for the dedicated and ephemeral privacy flows. #Cortensor #DevLog #Privacy #EncryptedInference #DedicatedNodes #EphemeralNodes #Testnet1a #DePIN

🗓️ Weekly Focus – Phase #3 Monitoring, v3 Session Prep & Privacy Iteration This week is about supporting Phase #3 live operations, continuing node restructuring for v3 agent flows, and pushing Private Inference 1.0 through a focused testing enhancement cycle. 🔹 Phase #3 – Support, Monitoring & Stats - Continue active support and monitoring across the phase, including routing, miners, validators, dashboards, and L3 stats. - Use the latest phase data to track stability, performance, and node behavior. 🔹 Node Restructuring v3 Session Prep - Node restructuring is already underway and forming the session topology we want for v3 /delegate and /validate. - We already have a dedicated 3-node-per-session setup in place. - Next step is preparing an additional 5-node session so we can use it on v3 endpoints and get redundancy/consensus-style testing ready. 🔹 Private Inference / Privacy Feature 1.0 – Testing Week - Private Inference 1.0 is now ready for deeper testing. - This week we’ll run a series of tests, fill the remaining gaps, and improve the UX around the flow. - Testing will use all 4 router endpoints (Corgent Bardiel), covering both dedicated-node sessions and ephemeral nodes from the general pool. 🔹 Privacy Scope & Module Enhancements - There may also be an upgrade to the PrivacySetting module as part of this iteration. - Task-scoped encryption is already supported and may drive a small PrivacySettingData upgrade so users can opt in to task-level encryption, while keeping session-level encryption as the default path. 🔹 Offchain Payload Configuration – Design / Deep Assessment - Spend time deepening the design for configurable offchain payload storage per router/operator. - Focus on code path clarity, config-change edge cases, and how this should behave as part of the real data lifecycle rather than just an env toggle. This week is mainly about v3 /delegate & /validate preparation, privacy feature testing enhancement, and deeper assessment of offchain payload configuration so these pieces are ready for stronger execution in the coming phase work. #Cortensor #Testnet #Phase3 #AIInfra #DePIN #Corgent #Bardiel #Delegate #Validate #PrivateAI #L3

🛠️ DevLog – Privacy Key Endpoints Now Live on All 4 Router Surfaces We’ve now updated all 4 router endpoints so the privacy feature’s key-request routes are exposed across both Cortensor and Bardiel surfaces on testnet0 and testnet1a. 🔹 What’s now exposed - POST /api/v1/auth/payload_enc_key/session - POST /api/v1/auth/payload_enc_key/task 🔹 Updated router surfaces - router1-t0.cortensor.app - router1-t0.bardiel.app - router0-t1a.cortensor.app - router0-t1a.bardiel.app 🔹 Why this matters - These are the key endpoints miners and dashboards need for the current privacy / encrypted inference flow. - With these now exposed on all 4 surfaces, the router side is fully prepared for broader E2E testing and regression checks around privacy features on both environments. 🔹 What’s next - Continue full-flow privacy testing across dedicated ephemeral paths. - Keep checking regressions while these newer privacy flows are exercised more broadly across testnet0 and testnet1a. #Cortensor #DevLog #Privacy #EncryptedInference #Bardiel #Corgent #Testnet0 #Testnet1a #DePIN

🛠️ DevLog – Offchain Storage Configurability: Next Step After Privacy Basics Now that the basic privacy v1.0 building blocks are in place, one of the next follow-up items is offchain storage configurability. 🔹 What we’re assessing now - Today, our offchain/S3 configuration is still spread across a few places: - router path, where user/app payloads get uploaded to offchain storage - miner path, where miners resolve URNs from chain/offchain and read payloads back - That’s workable for current testing, but too rigid for the longer-term privacy/data-ownership direction. 🔹 What we want to do - First, assess all the places that need to change. - Second, centralize these offchain storage settings into one place. - Third, make them env/config driven so operators can point to their own S3/object storage. - If nothing is set, it should fall back to the current default S3/offchain path we use today. 🔹 Why this matters - Privacy is not only about encryption keys - it also ties into where the encrypted data lives. - Longer term, this lets: - router/node operators choose their own storage backend - session/app owners keep stronger control over where their data is persisted - privacy data ownership fit together more naturally This will be one of the next action items in the coming weeks while we continue testing privacy v1.0 flows next week. #Cortensor #DevLog #Privacy #OffchainStorage #EncryptedInference #DePIN

🛠️ DevLog – Offchain Data Storage Will Become Configurable One more item surfaced while iterating on the privacy flow: we need to make offchain payload storage more configurable. 🔹 Current limitation - Right now, offchain payloads are stored in our own default S3 path / bucket setup. - That works for testing, but it’s too rigid for the longer-term direction. 🔹 What we want to change - Move offchain storage settings into config / env options so each operator can point to their own S3 bucket or object-storage setup. - This makes the storage layer more portable and less tied to one default infra path. 🔹 Why it matters - Longer term, the goal is: - operators control their own offchain storage - users/apps keep stronger control over their data - and with encryption, storage ownership data privacy fit together more cleanly This is separate from the current privacy v0.5 testing, but it’s clearly part of the same broader direction around data ownership and private inference. #Cortensor #DevLog #OffchainStorage #Privacy #EncryptedInference #DePIN

🛠️ DevLog – This & Next Week: Real E2E Privacy Testing on Testnet0/Testnet1a We’ll be spending this week and next week doing more real end-to-end testing of the privacy flows on testnet0 and testnet1a. 🔹 What we’ll be doing - Run more full privacy E2E cases across both environments: - dedicated private sessions - ephemeral private sessions - Keep adjusting router / endpoint setup so the encryption-key flows are properly exposed and testable. - Tighten dashboard UX and fix rough edges as they surface during real usage. 🔹 What we expect during this phase - Some gaps will likely show up around: - router ↔ miner ↔ dashboard integration - privacy UX / key fetch / cache flows - regression around existing non-private paths - We’ll use this time to fix those gaps and refine the flow instead of pushing wider too early. 🔹 In parallel - We’ll also keep a light eye on the next storage-related item: - making offchain payload storage more configurable over time, so privacy can align better with operator-controlled data paths. So the focus for now is simple: test the privacy flows for real on testnet0/testnet1a, fix what breaks, and smooth out the UX/integration path. #Cortensor #DevLog #Privacy #EncryptedInference #Testnet0 #Testnet1a #DePIN

🛠️ DevLog – Privacy v1.0 Updates Now on Testnet1a We’ve now pushed the latest PrivacySettingData module to testnet1a, including the newer support needed for ephemeral private sessions. The latest dashboard updates are also deployed there now. 🔹 What this means - Testnet1a now has the updated privacy data path for both: - dedicated private sessions - ephemeral private sessions - Dashboard is also aligned enough to keep exercising those flows from the UI side, not just from isolated backend tests. 🔹 What’s next - Main focus now is testing, regression checks, and filling remaining gaps across: - router ↔ miner privacy flow - dashboard privacy UX - dedicated ephemeral session behavior We’ll keep tightening rough edges as they show up before treating these flows as more stable.

🛠️ DevLog – Latest Privacy Dashboard Changes Live on Testnet0 We’ve deployed the latest dashboard privacy changes to testnet0 so it now supports both: 🔹 Dedicated private sessions - Current v0.5 dedicated-node privacy flow is live on the latest testnet0 dashboard. 🔹 Ephemeral private sessions - Current v1 rough flow is also now surfaced on the latest testnet0 dashboard. With testnet0 now updated on the dashboard side, we’ll start running more full E2E privacy tests on the testnet environment from here. 🔹 What’s next - If the latest flow looks stable enough, we’ll keep pushing forward with wider test coverage. - We’re also deploying the latest PrivacySettingData module (v1, covering both ephemeral dedicated paths) to testnet1 shortly. - Right now, testnet0 is the most up-to-date environment, including the dashboard changes. So the main focus now is simple: run more full-flow tests, refine what breaks, and harden both privacy paths before broader rollout. #Cortensor #DevLog #Privacy #EncryptedInference #Dashboard #DedicatedNodes #EphemeralNodes #Testnet0 #DePIN

🛠️ DevLog – Privacy Flows Working Roughly on Testnet0, More Testing Today At this point, both privacy paths are now working in rough form on testnet0: 🔹 Dedicated private sessions (v0.5) - Router-driven private / encrypted flow is working end to end in rough form. - Dashboard can fetch/cache the key and show decrypted input/output for the authorized owner. 🔹 Ephemeral private sessions (v1.0) - We’ve also now covered the first rough E2E case for ephemeral-node privacy. - The critical code path is there, but it still needs more regression testing and refinement. 🔹 What we’re doing today - Run more full-flow tests on both dedicated and ephemeral privacy paths. - Refine rough edges across router, miner, privacy settings, and dashboard UX. - Keep tightening the owner-side dashboard flow, key handling, and private task/result views. 🔹 Rollout approach - We’ll keep all of this confined to testnet0 for now while we polish the flows and UI further. - Once the dashboard side and regression pass feel cleaner, we’ll push the same privacy flow more fully into testnet1a as well. So the main shift now is from “can this path work at all?” to “can we make both privacy flows stable and usable enough before wider rollout?” Own Your Key. Own Your Data. #Cortensor #DevLog #Privacy #EncryptedInference #DedicatedNodes #EphemeralNodes #Testnet0 #DePIN