build(deps): bump actions/setup-java from 5.0.0 to 5.2.0#4
Open
dependabot[bot] wants to merge 1 commit into
Open
build(deps): bump actions/setup-java from 5.0.0 to 5.2.0#4dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 5.0.0 to 5.2.0. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@dded088...be666c2) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: 5.2.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
decentrathai
pushed a commit
that referenced
this pull request
Jul 4, 2026
… avatars, share-sheet Group send (#10/#11): surface no-recipient/invite failures (was a silent Log.w) via a GroupSendResult banner; rethrow CancellationException in invite/memo retry (invites no longer vanish on back-nav); check SubmitResult so a rejected tx isn't reported "sent" (also fixes 1:1 sends); preserve composer text on failure; per-member invite status + Resend action in group settings. AI top-up: skip ai-topup: memos in convertToConversations so top-ups don't appear as chat conversations (#9); reorder top-up sheet — Pay-with-wallet first, copy-address prominent, QR last (#5); new top-up history view. Conversation mode (#1): ZMODE authenticated control message (cloned from the ZEXP/B17 pattern) — in-chat pill both sides + safe auto-adopt (free modes only, pubkey known, mode not explicitly set; never VAULT); explicit-VAULT stays sticky against rotation ZBOOTs. Avatars (#12): AvatarStore + one ZchatAvatar composable across all render sites; editable self / contact-override / admin-only-group photos (local, Phase 1); wired into wallet wipe. Share (#3/#4): ACTION_SEND / SEND_MULTIPLE intent-filters (ZCHAT is now a system share target); in-app SharePicker; "Send via ZCHAT" primary button on AI images; enlarged generic share button; Forward re-pointed at the in-app picker. Backend (deployed separately on moltbot): tiered fast-credit (1-conf <=$50, 3 above), wider watcher lookback, Telegram top-up notify. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
decentrathai
pushed a commit
that referenced
this pull request
Jul 9, 2026
…nonicalization, log redaction From the deep multi-agent audit (each finding adversarially verified; the KEX fix had its own 3-agent review — ship-with-nits, all legit flows verified unaffected). #3 (HIGH) KEX/KEXACK key substitution. The KEX signature is verified against the payload's OWN pubkey (a self-signature), so it does NOT authenticate the sender as an established peer — an attacker who can attribute a KEX/KEXACK to a conversation could self-sign a SUBSTITUTE E2E key, which the code then flagged AND overwrote (real peer can't decrypt = DoS; MITM if the banner is dismissed). Fix: mirror the legacy E2E_INIT guard — refuse to auto-overwrite an established key (flag + keep the old key + return; no root/KEXACK/marker changes). First contact and same-key re-exchange still store; a genuine reinstall re-establishes via user-initiated Reset Encryption (which clears the key). Also gate the KEX first-contact convId REMAP on an unestablished peer so a self-signed KEX can't repoint our outbound convId for an established contact. #4/#7 (HIGH/LOW) decrypted plaintext at rest. groupMsgPrefs (decrypted GROUP message text) and pendingMsgPrefs (decrypted NOSTR message text + peer addresses) were UNENCRYPTED SharedPreferences. Switched both to AES256-GCM EncryptedSharedPreferences (distinct _encrypted files) with a one-time migration that moves existing entries into the encrypted store and CLEARS the old plain files so nothing decrypted lingers at rest. #5 (MEDIUM) kick/leave roster canonicalization. GROUP_KICK/GROUP_LEAVE matched the roster by exact address while every other op canonicalizes (resolvePeerAddress), so under UA-representation drift a kicked/left member was never marked LEFT locally — left ACTIVE, still able to inject old-epoch messages / inflate the count. Fix: match on resolvePeerAddress both sides; insert a LEFT tombstone when the kicked member isn't in the local roster. #9 (LOW) log redaction. parseMemo logged memo content (plaintext/ciphertext) and a raw convId; E2EEncryption.decrypt logged a ciphertext prefix. Removed the content and redacted the convId (don't rely on release-only stripping — debug never strips). Deferred follow-ups (pre-existing / LOW): #6 per-author GROUP_MSG signature (protocol change); #8 no-collector inbound stranding (self-heals on foreground resume; a periodic recovery has a decrypt-churn tradeoff); the KEXACK-side convId remap (entangled with the legitimate #205 payload-address fallback); the history re-scan false key-changed banner (no message loss — the guard keeps the current key). Validation: -Werror clean; ui-lib unit suite 458/458 green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LeV8KiSJk23B9wamRBdzmp
decentrathai
pushed a commit
that referenced
this pull request
Jul 11, 2026
#4) New ZPROF ZMSG type propagates the user's self-avatar to ESTABLISHED contacts so it renders as their default contact avatar (a local override still wins). MONEY-SAFE: avatar bytes ride NostrChatBridge.publish (free NIP-17 gift-wrap) ONLY — there is NO on-chain / VAULT / Zcash-transaction path, so it can never spend ZEC; targets are gated on getPeerNostrPubkey(peer) != null (unknown-pubkey peers are silently skipped), and the on-chain scan explicitly skips ZPROF so an avatar is never adopted from a chain memo. Wire format `ZPROF|v1|<xferId>|<idx>/<total>|<sha16>|<b64chunk>`: the 256x256 JPEG (<=50KB) is Base64'd and sliced into 16KB chunks (relay-safe under NIP-17 double-seal), reassembled by a bounded, thread-safe Reassembler (<=8 in-flight, <=32 chunks, <=256KB, 5-min stale eviction, idempotent to relay replays, SHA-256 integrity check before save). No third-party media host (unlike ZFILE) — stays inside the encrypted DM. Send is triggered after the user sets/changes their self photo (ChatListView picker -> onSelfAvatarChanged -> broadcastSelfAvatarToContacts, NonCancellable). Receive is a new ZPROF branch in observeNostrInbound, TOFU-guarded (#187) like ZMODE. Also (bug-a): the self-avatar previously rendered only as a 32dp chat-list circle; it now also renders at 72dp on the "My Address" (ZchatReceive) screen so the owner sees their own photo. ChatViewModel gains an avatarStore ctor param (Koin auto-wired via viewModelOf + singleOf(::AvatarStore)); verified: app launches with no DI crash. Verified: ui-lib compiles (-Werror) + adversarial money-safety audit PASS (NOSTR-only, established contacts only). Full live 2-device propagation is env-gated (clean re-pair). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: d9c3ab19-007f-4ea9-a804-685017ee234f
decentrathai
pushed a commit
that referenced
this pull request
Jul 12, 2026
…trip on-device Round-trip PROVEN on 2 devices (both on this build): Honor set photo → "delivered to 1 established contact" → NOSTR relay → Seeker rewrote the peer's contact-avatar file (size+mtime changed the instant the broadcast landed). The earlier "broadcast never fires" was a mis-diagnosis: an `adb logcat -s ZCHAT_PROF:D` tag filter hid the send lines, and the receiver test device had been left on the pre-#4 build. v2.12.1's version-flow observer works, but relied solely on it. This restores the DIRECT picker trigger (onSelfAvatarChanged → broadcast) so the send fires immediately on the picker return — before Honor/Huawei can kill the app — while the version-flow observer still handles the launch-retry (process-death) + new-contact cases. An AtomicBoolean in-flight guard dedupes the two triggers so one set = one broadcast. Adds concise ZCHAT_PROF trace logging (version tick, broadcast enter, peers/established/delivered). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: d9c3ab19-007f-4ea9-a804-685017ee234f
decentrathai
pushed a commit
that referenced
this pull request
Jul 12, 2026
…, See-all, wallet text, 0-ZEC/error audit Seven user-reported issues, root-caused + fixed (all adversarially verified money-safe, :ui-lib compiles -Werror): #7 TUNNEL first message broken receiver-side — the on-chain ZBOOT carries only a convId (no Zcash sender), so an unmapped convId stranded the message on a phantom "Unknown sender / not sent via ZCHAT" chat (reply disabled) and left the mode "shielded". Fix: attributeBoot() gives the on-chain ZBOOT the same signature-attribution the NOSTR path has (routeIncomingBoot stays the sole trust gate) → row re-keys to the real peer → banner gone, reply enabled, mode converges to Tunnel; + a synchronous first-contact convId→peer map write closes the catch-up sync race. No new spend (reply free-NOSTR-first, bounded). #1 OPEN (free) mode unavailable on a scanned invite — the My-Address AND Invite-Friend QRs encoded only the bare Zcash address, not the NOSTR contact code. Both now show a second QR carrying the zchat contact code, so a scan enables free OPEN (money-positive: no on-chain ZBOOT). #4 avatar REMOVE not propagating — added a ZPROF REMOVE tombstone (free NOSTR, established-only, dedup-tracked); removing your photo now clears it on peers via removeContactAvatar. #2 wallet Send-all missing — was gated on spendable-shielded>0; now gated on total-shielded, click still clamps to spendable (never over-spends). #3 See-all missing — un-gated the activity-widget header button (was hidden at <=5 txns). #5 wallet payment showed chat wording — InsufficientFunds sheet is now context-aware (PAYMENT/MESSAGE/SWAP). #6 0-ZEC raw exception (AmountTooSmall / co.electriccoin… leaked to UI) — 0-amount coerced to dust for on-chain (display==charge; Send-all excluded), "Free" dropped for on-chain modes (true free = OPEN/NOSTR), + a single Throwable.toZchatUserMessage mapper replaces every raw exception/FQCN leak with ZCHAT-voiced copy; ProposalDataSource double-wrap fixed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: d9c3ab19-007f-4ea9-a804-685017ee234f
decentrathai
force-pushed
the
dependabot/github_actions/actions/setup-java-5.2.0
branch
from
July 18, 2026 07:42
c2c83af to
97a7d73
Compare
decentrathai
pushed a commit
that referenced
this pull request
Jul 18, 2026
… avatars, share-sheet Group send (#10/#11): surface no-recipient/invite failures (was a silent Log.w) via a GroupSendResult banner; rethrow CancellationException in invite/memo retry (invites no longer vanish on back-nav); check SubmitResult so a rejected tx isn't reported "sent" (also fixes 1:1 sends); preserve composer text on failure; per-member invite status + Resend action in group settings. AI top-up: skip ai-topup: memos in convertToConversations so top-ups don't appear as chat conversations (#9); reorder top-up sheet — Pay-with-wallet first, copy-address prominent, QR last (#5); new top-up history view. Conversation mode (#1): ZMODE authenticated control message (cloned from the ZEXP/B17 pattern) — in-chat pill both sides + safe auto-adopt (free modes only, pubkey known, mode not explicitly set; never VAULT); explicit-VAULT stays sticky against rotation ZBOOTs. Avatars (#12): AvatarStore + one ZchatAvatar composable across all render sites; editable self / contact-override / admin-only-group photos (local, Phase 1); wired into wallet wipe. Share (#3/#4): ACTION_SEND / SEND_MULTIPLE intent-filters (ZCHAT is now a system share target); in-app SharePicker; "Send via ZCHAT" primary button on AI images; enlarged generic share button; Forward re-pointed at the in-app picker. Backend (deployed separately on moltbot): tiered fast-credit (1-conf <=$50, 3 above), wider watcher lookback, Telegram top-up notify. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
decentrathai
pushed a commit
that referenced
this pull request
Jul 18, 2026
…nonicalization, log redaction From the deep multi-agent audit (each finding adversarially verified; the KEX fix had its own 3-agent review — ship-with-nits, all legit flows verified unaffected). #3 (HIGH) KEX/KEXACK key substitution. The KEX signature is verified against the payload's OWN pubkey (a self-signature), so it does NOT authenticate the sender as an established peer — an attacker who can attribute a KEX/KEXACK to a conversation could self-sign a SUBSTITUTE E2E key, which the code then flagged AND overwrote (real peer can't decrypt = DoS; MITM if the banner is dismissed). Fix: mirror the legacy E2E_INIT guard — refuse to auto-overwrite an established key (flag + keep the old key + return; no root/KEXACK/marker changes). First contact and same-key re-exchange still store; a genuine reinstall re-establishes via user-initiated Reset Encryption (which clears the key). Also gate the KEX first-contact convId REMAP on an unestablished peer so a self-signed KEX can't repoint our outbound convId for an established contact. #4/#7 (HIGH/LOW) decrypted plaintext at rest. groupMsgPrefs (decrypted GROUP message text) and pendingMsgPrefs (decrypted NOSTR message text + peer addresses) were UNENCRYPTED SharedPreferences. Switched both to AES256-GCM EncryptedSharedPreferences (distinct _encrypted files) with a one-time migration that moves existing entries into the encrypted store and CLEARS the old plain files so nothing decrypted lingers at rest. #5 (MEDIUM) kick/leave roster canonicalization. GROUP_KICK/GROUP_LEAVE matched the roster by exact address while every other op canonicalizes (resolvePeerAddress), so under UA-representation drift a kicked/left member was never marked LEFT locally — left ACTIVE, still able to inject old-epoch messages / inflate the count. Fix: match on resolvePeerAddress both sides; insert a LEFT tombstone when the kicked member isn't in the local roster. #9 (LOW) log redaction. parseMemo logged memo content (plaintext/ciphertext) and a raw convId; E2EEncryption.decrypt logged a ciphertext prefix. Removed the content and redacted the convId (don't rely on release-only stripping — debug never strips). Deferred follow-ups (pre-existing / LOW): #6 per-author GROUP_MSG signature (protocol change); #8 no-collector inbound stranding (self-heals on foreground resume; a periodic recovery has a decrypt-churn tradeoff); the KEXACK-side convId remap (entangled with the legitimate #205 payload-address fallback); the history re-scan false key-changed banner (no message loss — the guard keeps the current key). Validation: -Werror clean; ui-lib unit suite 458/458 green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LeV8KiSJk23B9wamRBdzmp
decentrathai
pushed a commit
that referenced
this pull request
Jul 18, 2026
#4) New ZPROF ZMSG type propagates the user's self-avatar to ESTABLISHED contacts so it renders as their default contact avatar (a local override still wins). MONEY-SAFE: avatar bytes ride NostrChatBridge.publish (free NIP-17 gift-wrap) ONLY — there is NO on-chain / VAULT / Zcash-transaction path, so it can never spend ZEC; targets are gated on getPeerNostrPubkey(peer) != null (unknown-pubkey peers are silently skipped), and the on-chain scan explicitly skips ZPROF so an avatar is never adopted from a chain memo. Wire format `ZPROF|v1|<xferId>|<idx>/<total>|<sha16>|<b64chunk>`: the 256x256 JPEG (<=50KB) is Base64'd and sliced into 16KB chunks (relay-safe under NIP-17 double-seal), reassembled by a bounded, thread-safe Reassembler (<=8 in-flight, <=32 chunks, <=256KB, 5-min stale eviction, idempotent to relay replays, SHA-256 integrity check before save). No third-party media host (unlike ZFILE) — stays inside the encrypted DM. Send is triggered after the user sets/changes their self photo (ChatListView picker -> onSelfAvatarChanged -> broadcastSelfAvatarToContacts, NonCancellable). Receive is a new ZPROF branch in observeNostrInbound, TOFU-guarded (#187) like ZMODE. Also (bug-a): the self-avatar previously rendered only as a 32dp chat-list circle; it now also renders at 72dp on the "My Address" (ZchatReceive) screen so the owner sees their own photo. ChatViewModel gains an avatarStore ctor param (Koin auto-wired via viewModelOf + singleOf(::AvatarStore)); verified: app launches with no DI crash. Verified: ui-lib compiles (-Werror) + adversarial money-safety audit PASS (NOSTR-only, established contacts only). Full live 2-device propagation is env-gated (clean re-pair). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: d9c3ab19-007f-4ea9-a804-685017ee234f
decentrathai
pushed a commit
that referenced
this pull request
Jul 18, 2026
…trip on-device Round-trip PROVEN on 2 devices (both on this build): Honor set photo → "delivered to 1 established contact" → NOSTR relay → Seeker rewrote the peer's contact-avatar file (size+mtime changed the instant the broadcast landed). The earlier "broadcast never fires" was a mis-diagnosis: an `adb logcat -s ZCHAT_PROF:D` tag filter hid the send lines, and the receiver test device had been left on the pre-#4 build. v2.12.1's version-flow observer works, but relied solely on it. This restores the DIRECT picker trigger (onSelfAvatarChanged → broadcast) so the send fires immediately on the picker return — before Honor/Huawei can kill the app — while the version-flow observer still handles the launch-retry (process-death) + new-contact cases. An AtomicBoolean in-flight guard dedupes the two triggers so one set = one broadcast. Adds concise ZCHAT_PROF trace logging (version tick, broadcast enter, peers/established/delivered). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: d9c3ab19-007f-4ea9-a804-685017ee234f
decentrathai
pushed a commit
that referenced
this pull request
Jul 18, 2026
…, See-all, wallet text, 0-ZEC/error audit Seven user-reported issues, root-caused + fixed (all adversarially verified money-safe, :ui-lib compiles -Werror): #7 TUNNEL first message broken receiver-side — the on-chain ZBOOT carries only a convId (no Zcash sender), so an unmapped convId stranded the message on a phantom "Unknown sender / not sent via ZCHAT" chat (reply disabled) and left the mode "shielded". Fix: attributeBoot() gives the on-chain ZBOOT the same signature-attribution the NOSTR path has (routeIncomingBoot stays the sole trust gate) → row re-keys to the real peer → banner gone, reply enabled, mode converges to Tunnel; + a synchronous first-contact convId→peer map write closes the catch-up sync race. No new spend (reply free-NOSTR-first, bounded). #1 OPEN (free) mode unavailable on a scanned invite — the My-Address AND Invite-Friend QRs encoded only the bare Zcash address, not the NOSTR contact code. Both now show a second QR carrying the zchat contact code, so a scan enables free OPEN (money-positive: no on-chain ZBOOT). #4 avatar REMOVE not propagating — added a ZPROF REMOVE tombstone (free NOSTR, established-only, dedup-tracked); removing your photo now clears it on peers via removeContactAvatar. #2 wallet Send-all missing — was gated on spendable-shielded>0; now gated on total-shielded, click still clamps to spendable (never over-spends). #3 See-all missing — un-gated the activity-widget header button (was hidden at <=5 txns). #5 wallet payment showed chat wording — InsufficientFunds sheet is now context-aware (PAYMENT/MESSAGE/SWAP). #6 0-ZEC raw exception (AmountTooSmall / co.electriccoin… leaked to UI) — 0-amount coerced to dust for on-chain (display==charge; Send-all excluded), "Free" dropped for on-chain modes (true free = OPEN/NOSTR), + a single Throwable.toZchatUserMessage mapper replaces every raw exception/FQCN leak with ZCHAT-voiced copy; ProposalDataSource double-wrap fixed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: d9c3ab19-007f-4ea9-a804-685017ee234f
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
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.
Bumps actions/setup-java from 5.0.0 to 5.2.0.
Release notes
Sourced from actions/setup-java's releases.
Commits
be666c2Chore: Version Update and Checkout Update to v6 (#973)f7a6fefBump actions/checkout from 5 to 6 (#961)d81c4e4Upgrade@actions/cacheto v5 (#968)1b1bbe1readme update (#972)5d7b214Retry on HTTP 522 Connection timed out (#964)f2beeb2Bump actions/publish-action from 0.3.0 to 0.4.0 (#912)4e7e684feat: Add support for.sdkmanrcfile injava-version-fileparameter (#736)46c56d6Add GitHub Token Support for GraalVM and Refactor Code (#849)66b9457Update SapMachine URLs (#955)6ba5449Enhance error logging for network failures to include endpoint/IP details, ad...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)