Inspiration
Jane takes a bite of warm golden buns during a video call. Her friend Avon’s face lights up. She wants to send some, because an ordinary afternoon could use something lovely.
The thought is welcome. The delivery might not be. Perhaps there is already bread in the kitchen. Perhaps the recipient would enjoy choosing something later—or would love to brighten another friend’s day instead. “Thank you” and “Something different would work better for me” can both be sincere.
We want to preserve both sides of that moment: the giver’s pleasure in offering and the recipient’s freedom to choose. Gifting already feels natural in conversation. We explore personal-SI coordination that leaves relationships, permissions, and decisions with people.
When someone feels like giving a gift, we hope cumbersome steps need not make them put that feeling off. But the wish to give and the recipient’s circumstances do not always align. Recipients need choices that fit them, too, so gratitude can become another moment of warmth rather than an obligation or burden.
What it does
Lux Bakery Gift is a PayPal sandbox prototype for a bakery gift between friends.
The giver’s personal SI helps choose within a budget and coordinate the invitation. The recipient’s personal SI privately helps consider the offer, choose, and prepare a reply. SI means Super Intelligence, our project’s term for these helpers.
Each SI works with context its own person chooses to share. They coordinate authorized choices; they do not need to exchange private conversations or assume they know someone’s feelings.
First comes a clear invitation: “Jane sent you a bakery gift.” Then one primary question:
What works for you: bread, same-store credit, giving it to another friend, or no thanks?
The recipient can choose what suits them without having to justify it. Onward gifting is a positive choice, too: giving someone else that happiness may be what they most want to do.
In this design, the giver learns only the permitted accepted/declined status and any recipient-approved thank-you—not whether the recipient chose bread, credit, or another friend. The screen labels “Sender sees” and “Receiver sees” show that the receiver’s choice stays private: the sender sees only Accepted or Declined, plus thanks. A reply draft can be approved, rewritten, or skipped. Consequential actions stay under human approval.
For a delivery, the recipient would enter the necessary details; the giver would not need to know or check the address. The giver remains the payer. One question establishes the direction, not every delivery detail.
No personal SI? We propose that PayPal provide an SI through the invitation link, bringing help with the gift rather than leaving the recipient with a bare link. It would start with the authorized offer and available options, helping the person choose and carry out their approved decision.
In PayPal sandbox, we demonstrated a three-room payment prototype:
- Room 1 — Offer: the giver chooses a gift and authorizes payment.
- Room 2 — Decide: recipient acceptance leads to capture; final decline voids the uncaptured authorization. Separate accepted and declined runs demonstrate both outcomes.
- Room 3 — Support and shop: after a clip of steaming golden buns, creator-support payments, self-purchase, and friend-gifting branches have also been demonstrated. Support and self-purchase use capture; friend gifts follow authorization and the recipient’s decision.
The latest payment status stays below the conversation. The payment core gives the proposal a practical foundation: an authorized choice has an operational outcome.
The wider proposal lets someone immediately offer a gift or donation while viewing a live stream, recorded video, or existing post—or buy a recommended product. The creator need not be live at that moment. The viewer’s SI and the creator’s SI would coordinate the authorized offer. The creator could accept or decline; their SI could prepare a gentle decline, sent only with approval. The same principle carries across borders: help people act on a generous impulse while respecting the other person’s choice.
How we built it
During the hackathon, we connected conversational suggestions, human choices, spending caps, and PayPal payment states in the bakery and creator-support/shopping prototype.
Node.js and Express run scene-based suggestion and payment operations. PayPal JavaScript SDK v6 in sandbox provides checkout and human approval; PayPal Orders v2 and authorization operations support authorize → capture/void. Gemini supplies short, structured JSON suggestions from limited scene context.
People set spending caps; the server checks amounts against them. The SI summary keeps the item, amount, and cap in view, and final PayPal approval remains human. SI replies use Gemini with a three-second limit and an honestly labeled offline script fallback. The badges “SI: live” and “SI: offline script” show which mode is in use.
We made a 2:49 demo video from a real PayPal sandbox screen recording, with English captions and no narration. The opening video-call scene and the steaming-bread clip and photo are generated media, and they are labeled as generated in the video.
Challenges we ran into
The hardest design problem was keeping the gift warm while leaving the recipient real room to choose. We needed a payment flow in which the receiver can choose bread, same-store credit, another friend, or no thanks, and the sender still sees only Accepted or Declined, plus thanks.
Connecting those choices to PayPal was equally careful work. Acceptance should capture an authorization; a final decline should void it. Spending caps had to be visible and enforceable, with the person still giving the last PayPal approval.
We also wanted SI help to stay honest. Replies use Gemini with a three-second limit; when that is not available, an offline script continues the demo and is clearly labeled. We were careful not to over-claim: same-store credit remains a concept, and onward delivery is part of the proposed experience, not a finished commercial service.
Accomplishments that we're proud of
We are proud that the three-room sandbox prototype is live, and that a choice in the conversation has a real payment outcome—capture or void—in PayPal sandbox, with no real money.
We are proud of the “Sender sees” and “Receiver sees” labels, which make the privacy rule visible rather than hidden, and of the honest “SI: live” and “SI: offline script” badges.
And we are proud of the 2:49 demo video: a real sandbox screen recording, with English captions, no narration, and generated opening and bread clips that are labeled as generated.
What we learned
We learned that a generous impulse and the recipient’s circumstances do not always align, and that both “thank you” and “something different would work better for me” can be sincere. Technology should carry the kindness without turning gratitude into an obligation.
We learned that privacy can be designed into a payment flow, not added afterwards, and that clear on-screen labels help people trust what they are seeing. We also learned to keep the prototype honest about its scope: show the payment core we built, and keep proposed ideas clearly marked as proposals.
Each person’s SI can coordinate the tedious steps; people decide for themselves. We want warm technology that carries kindness while respecting each other’s choices.
What's next for Lux Bakery Gift
The next scoped addition is a same-store-credit option in the existing sandbox. Its design draws on gift-receipt return practice: retain value with the recipient, hide the gift price, and keep the credit choice private from the giver. Equal-price alternatives, top-ups, retained remainder, and a broader gift wallet are longer-term possibilities.
We also hope to take further the wider idea of acting on generosity while watching a live stream, a recorded video, or an existing post.
The sandbox demonstrates the payment core, not a finished commercial service. Independent personal-SI coordination, a PayPal-provided SI through a link, recipient-entered delivery details, and onward delivery form the proposed experience. Historical onward-gift acceptance/capture tests do not establish actual third-party delivery. Credit remains a concept: no redeemable credit or wallet balance is issued. Onward delivery is outside this build scope.
