Replaced mock signal signatures with real SEP-53 Ed25519 proof-of-wallet-ownership: clients sign the payload via the wallet, the server verifies each signature with Keypair.verify and rejects invalid or forged ones, and the UI shows a verified badge based on a persisted signature_verified flag. Includes DB migration, unit tests, and doc updates. - #193
Merged
Conversation
|
@DevScoopee Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
…in filter, an IntersectionObserver was added to pause rendering when off-screen, and prefers-reduced-motion support was wired into both the component and the tactical stylesheet. The original AnimatedNoise component ran a requestAnimationFrame loop that allocated and painted random pixel data every frame, causing unnecessary GPU and CPU load on mobile devices. The rewrite removes the canvas entirely and instead renders an SVG feTurbulence texture as a CSS background, which the browser composites on the GPU with near-zero cost. An IntersectionObserver monitors whether the element is in the viewport and drops the animation to zero when it scrolls out of view. A matchMedia listener detects the system prefers-reduced-motion setting and disables the grain animation accordingly. The tactical-command stylesheet was updated with matching keyframes and a reduced-motion media query so the tactical background grain also respects the accessibility preference. The CRT collection preview was already using a static SVG grain and required no changes. Closes PHASE-STELLAR#35
…let-ownership: clients sign the payload via the wallet, the server verifies each signature with Keypair.verify and rejects invalid or forged ones, and the UI shows a verified badge based on a persisted signature_verified flag. Includes DB migration, unit tests, and doc updates. The problem was that signal and reply posts stored a mock signature equal to the wallet address, which proved nothing cryptographically and let anyone claim authorship of any wallet. The solution establishes a shared SEP-53 scheme in which the client builds a canonical payload, derives a fixed-size SHA-256 digest message to stay within wallet message size limits, and signs it via the selected wallet's signMessage. The server then independently reconstructs the same payload and verifies the signature using Stellar's Keypair verify method, rejecting missing, malformed, or forged signatures with a 400 response. Because verification is stateless and uses only public keys, the server never touches private keys, and the signatures are content-bound and forge-resistant. The result is persisted as signature_verified, which drives the badge in the UI to distinguish verified posts from legacy ones, and the new columns are migration-safe through an idempotent alteration. Voting and scheduling operations still use the lightweight identity signature, since they are not proof-of-ownership content submissions and were intentionally left unchanged. Closes PHASE-STELLAR#37
…e-Verification-(SEP-0023-/-Freighter)
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
2 participants
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.
The problem was that signal and reply posts stored a mock signature equal to the wallet address, which proved nothing cryptographically and let anyone claim authorship of any wallet. The solution establishes a shared SEP-53 scheme in which the client builds a canonical payload, derives a fixed-size SHA-256 digest message to stay within wallet message size limits, and signs it via the selected wallet's signMessage. The server then independently reconstructs the same payload and verifies the signature using Stellar's Keypair verify method, rejecting missing, malformed, or forged signatures with a 400 response. Because verification is stateless and uses only public keys, the server never touches private keys, and the signatures are content-bound and forge-resistant. The result is persisted as signature_verified, which drives the badge in the UI to distinguish verified posts from legacy ones, and the new columns are migration-safe through an idempotent alteration. Voting and scheduling operations still use the lightweight identity signature, since they are not proof-of-ownership content submissions and were intentionally left unchanged.
Closes #37