feat(sdk): in-app notification inbox types + API methods - #265
Open
trevormil wants to merge 4 commits into
Open
Conversation
Adds the SDK surface for a per-user in-app notification inbox: - iNotificationDoc / NotificationDoc + NotificationType - extend iNotificationPreferences with in-app channel + per-event flags - notification websocket message types (websockets.ts) - BitBadgesAPI methods: getNotifications, getUnreadNotificationCount, markNotificationsRead, updateNotificationPreferences (+ routes + request types) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add optional `activity?: iTransferActivityDoc<T>` to iNotificationDoc / NotificationDoc. The constructor wraps it in a real TransferActivityDoc and the generic convert() recurses into it, so the frontend can render transfer notifications with the standard transfer-activity components without a refetch (and it stays self-contained for realtime-pushed rows). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…bank_send Restructure NotificationDoc into a standardized presentation envelope (title [now required], message, link, collectionId, address) plus a type-specific `payload` (iNotificationPayload) surfaced only in the drilldown. `type` is the discriminator; add `bank_send`. Replaces the flat activity/data/txHash/from fields. This is the extension point for new inbox event types. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
New NotificationType 'intent_satisfied' with an intentSatisfied payload (approvalId, approverAddress/maker, filler, collectionId, coins, tokenIds, legCount) for collapsing a multi-leg intent fill into one inbox event. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 1 of 3 for the in-app notification inbox (SDK → indexer → frontend).
Adds
iNotificationDoc/NotificationDoc— a per-recipient inbox document (type,read,createdAt,collectionId,txHash,from,initiatedBy, denormalized displaydata) +NotificationTypeunion.iNotificationPreferenceswith an in-app channel:inAppEnabled,inAppTransferActivity,inAppClaimActivity(the existing email/discord prefs are untouched).websockets.ts) for the per-user push channel.BitBadgesAPImethods:getNotifications,getUnreadNotificationCount,markNotificationsRead,updateNotificationPreferences(+ routes inroutes.ts, payload/response types inrequests.ts).Notes
getNumberFieldNames()lists every number-typed field; no central doc union/registry exists in this SDK so nothing else to register; barrels are wildcard.bun run build(tsc CJS + ESM + tsc-alias + madge circular-dep check) passes clean.The indexer + frontend PRs depend on these types.
🤖 Generated with Claude Code