rfc17-user-bgp-status

[juan-malbeclabs]

This pull request introduces RFC 17, which proposes a new onchain mechanism to track the real BGP session status for each user, closing the gap between configuration and actual client connectivity. The RFC details new fields to be added to the User account, a new instruction for updating BGP status, and changes to telemetry collection and SDKs. This enhancement will enable more accurate diagnostics and user lifecycle management by making BGP session state observable onchain.

User account and onchain status tracking:

• Adds three new fields to the User struct: bgp_status (session state), last_bgp_up_at (last time session was Up), and last_bgp_reported_at (last time status changed), requiring a 17-byte account reallocation on first write.
• Introduces a new instruction, SetUserBGPStatus, allowing authorized metrics publishers to update BGP status for each user, with strict validation.

Telemetry and agent changes:

• Updates the telemetry collector to determine each user's BGP state after every collection tick and enqueue onchain status updates via the new instruction, using a background worker for reliability.

SDK and compatibility:

• Requires updates to SDKs (Go, TypeScript, Python) to handle the new fields, ensuring backward compatibility by treating missing fields as

[ben-dz]

I think overall DZDs should be using their telemetry key to write this data onchain. I don't think we want this as part of the onchain user, since I think we don't want to give DZDs the authority to modify user accounts.

instead, probably a separate onchain program (bgp-monitor?) that maintains this data. Eventually perhaps add a cross-program call to have the bgp-monitor call into serviceability to delete users when uploaded data shows stale sessions.

[juan-malbeclabs]

We would be creating an instruction that can be executed by the agent using the telemetry PK, which is only allowed to update this field in the user account. It does not have permission to modify any other fields. Additionally, it internally sets the slot values.

New instruction: SetUserBGPStatus (variant 94)

[ben-malbeclabs]

Approved from a conceptual perspective, would be good to have another dev confirm too.

[snormore]

Agents should write their status whether it changed or not. Otherwise last_bgp_reported_at isn't actually useful to determine if the agent is silent/reporting.

[elitegreg]

This is more of a devil's advocate comment. What if we had a field on the device to track when it last reported bgp sessions to the smartcontract and only update users when the state changes, thus reducing writes?

[snormore]

That seems fine too, or something like this

[juan-malbeclabs]

It should only write the state when the value has changed, or after a sufficiently long interval since the last write, to refresh the timestamp (slot).

[snormore]

Not sure we need to write this every collectBGPStateSnapshot tick (5m), especially if we write status no matter if it has changed. It should probably be on a slower moving ticker, like 1h or something. The use case of this doesn't need 5m granularity, right?

[elitegreg]

I think if we update everything, I agree it should be slower. If we only write deltas, then I think it could be event driven with throttling.

[juan-malbeclabs]

It should only write the state when the value has changed, or after a sufficiently long interval since the last write, to refresh the timestamp (slot).

[martinsander00]

Would be RFC 18 I think.

[juan-malbeclabs]

This was a reference at the time of writing the RFC; it will be updated during implementation.

[martinsander00]

104* since 94-103 are taken

[juan-malbeclabs]

This was a reference at the time of writing the RFC; it will be updated during implementation.

[snormore]

I kind of think this should live in a different account/structure, like UserBGPSession, if not just generically in the record program. What do you see as the downsides of a different account/structure for these vs living directly on User?

[juan-malbeclabs]

1. The Record program is intended to register on-chain data from off-chain applications, but it does not provide control over who can write or read that data, so it does not seem applicable in this case.

2. I do not see a strong reason to introduce a new account. For User, this is simply adding three additional fields with a 1:1 relationship to the user and its BGP session state. Splitting it into a separate account would require reading two accounts just to retrieve a small amount of additional data associated with the user.

3. Additionally, it is necessary to access the Device relationship to verify the authority that can manage the users connected to the device. Therefore, interacting with these instructions will inevitably require reading both the User and the Device accounts.