Lightning Stream 0.2.3

The source of the two GNU LGPL libraries the Stream Gateway image (xbt-datum-gateway) links statically, exactly as its build used them: libmicrohttpd and argp-standalone, with SHA256SUMS-datum-gateway-lgpl. The rest of the source is this repository at this tag; scripts/datum_gateway_build.sh builds and links the gateway, so it can be rebuilt or relinked against modified versions of these libraries. The Linux package is the repository itself: see docs/LINUX.md.

Lightning Stream 0.2.2

The source of the two GNU LGPL libraries the Stream Gateway image (xbt-datum-gateway) links statically, exactly as its build used them: libmicrohttpd and argp-standalone, with SHA256SUMS-datum-gateway-lgpl. The rest of the source is this repository at this tag; scripts/datum_gateway_build.sh builds and links the gateway, so it can be rebuilt or relinked against modified versions of these libraries. The Linux package is the repository itself: see docs/LINUX.md.

Lightning Stream 0.2.0

The source of the two GNU LGPL libraries the Stream Gateway image (xbt-datum-gateway) links statically, exactly as its build used them: libmicrohttpd and argp-standalone, with SHA256SUMS-datum-gateway-lgpl. The rest of the source is this repository at this tag; scripts/datum_gateway_build.sh builds and links the gateway, so it can be rebuilt or relinked against modified versions of these libraries. The Linux package is the repository itself: see docs/LINUX.md.

Lightning Stream 0.2.3 for StartOS

Lightning Stream 0.2.3 for StartOS.

Usability, from Mike's hands-on run of 0.2.2 on Umbrel. The wallet UI, the VPN service and the signer
change (one read added; payments are unchanged).

• Buy and Sell. The main menu's Services is now Buy, beside Sell. Settings keeps Setup, Your node,
  Spending rules and Keys and backup as tabs; Records, Stream relays and Old channels are under Advanced.
• Get started on Home. A list of what is left (approval key, node, starter rules, a shop, a first
  purchase), with the next step's button. The demo shop is added and allowed in one press, a service's page
  says when its shop isn't allowed yet, with the button, and a shop is named by its listing everywhere.
• Real money in the same signature as the rules. On mainnet, signing the starter rules carries one box,
  "I understand the app pays with real money, within these rules", which writes the same confirmation Your
  node writes; no separate page. Your node can still turn paying with real money off and on.
• One figure for what a payment cost. Paid is what left your node: the shop's amount plus the routing fee,
  from the wallet's settled record, with its two parts ("903 sats (900 + 2.009 fee)"). Wallet, Live
  connections and the visit bar name the same three figures: paid, used and credit left. A booking before a
  payment settles is shown as reserved, never as paid.
• Credit you have with a shop. After a connection closes, what it left with the shop shows on Sellers, on
  the shop's service page and on the Wallet's row. A visit that runs on earlier credit says how much is left.
• One Stop. Stopping a visit also closes its connection with the shop, unless another visit to that shop
  is still using it.
• Allowed means paid. A shop allowed through its Lightning node's line in your rules is shown as allowed.
  Before, Sellers, AI and Spending rules said it couldn't be paid while the wallet paid it. A node line is
  shown as the shop's Lightning node, not as a coin address. A shop with no node on file gets a one-press fix.
• VPN exits. Every exit the VPN service finds is listed, also a paid exit whose country isn't checked yet.
  Before, a paid exit such as the Pi Demo's (SV, 1,000 sat/GB) was found but never shown. Found on Nostr on
  the VPN page lists the exits your relays carry, with Add this exit; your devices then prefer it whenever
  it meets their rules.
• Hashrate. A shop that goes Private is paid at its key address. Before, the hashmaker went on publishing
  the old web address and every rental failed at its first piece of work.
• Plain words and fewer keys. Refused payments in Wallet activity are explained as the refusal pages
  explain them. A shop is named by its name on the service and visit pages and in Wallet activity. Your
  node's raw status is under Technical details. The AI address is also given by the box's IP address.
• Faster first pages. Found on Nostr, Stream relays, VPN and Hashrate are asked once at start, in the
  background. The signer's slow-changing reads now serve pages for 20 s (they were kept 3 s, too short to
  help).
• Also: the agent access key is shown only after Show the access key; starter rules' least node limit is
  1,000,000 sats; Setup counts each seller and step once; Live connections shows a rate only while streaming.
• The look of lightning-stream.com. The app is dark by default, with the website's near-black ground,
  lightning-yellow main buttons and amounts, white-blue accents, its Inter type and its mark. A light theme
  in the same colors is one button away in the bar, and the browser remembers it. The background's electric
  river is slower and finer, in yellow and electric blue, still reacts to the pointer and to clicks, and
  stays still with reduced motion and on low-power devices. Every page works at phone width.

It moves real funds on mainnet and has been tested there with small amounts only. Start with low limits.

What you need first

• StartOS 0.4.0.2 or later.
• Knots BLAKE2b, the node for the Bitcoin BLAKE2b chain.
• Lightning Fork 0.21.4-beta.21.1:2 or later, from its StartOS registry, https://start9.paulscode.com/, with a channel.

Install from the Lightning Stream registry, https://registry.lazarus-xbt.xyz (Marketplace → Switch → Add). StartOS then shows updates as they come; earlier installs update in place. Or sideload the .s9pk for your server (x86_64 or aarch64) under System → Sideload a service. The step-by-step guide is docs/STARTOS.md.

Connecting your Lightning node: Lightning Stream asks Lightning Fork for its own key. Run Lightning Fork's Grant app access task for Lightning Stream to approve it; nothing to paste. The key can only pay, within your spending rules, and you can revoke it in Lightning Fork at any time. Selling needs two invoice-only keys that you make in Lightning Fork and paste on the Sell page, for now.

SHA256SUMS lists the files' checksums.

Lightning Stream 0.2.2 for StartOS

Lightning Stream 0.2.2 for StartOS.

A fix release for a first purchase, from a tester's hands-on run of 0.2.1.

• Sellers by name. Sellers, Spending rules, Wallet activity, Live connections, Found on Nostr and the visit
  pages name a shop by its listing ("Lightning Stream Genesis"), never by its key or its made-up
  ….shop.invalid address. Found on Nostr marks shops already on your list.
• Who may be paid is a list. Spending rules show one row per seller: name, key or address, its Lightning
  node, and Remove. An edit can no longer cut a seller's node off; before, a long line wrapped in a text box
  and editing it could drop the node, after which every payment to that seller was refused. A seller with no
  node, or with a node other than the one the shop vouches for, is warned about before you sign. Removing a
  seller from Sellers points you to the rules where it is still allowed.
• No blank pages. When the wallet won't pay (a seller not allowed, no route, a limit or cap, your node over
  "The most your Lightning node may hold"), the app shows why in plain words, what fixes it, and links, with
  the wallet's own words under Details.
• Your node can't send. Before opening a shop's app or downloading, and on Browse, the app warns when your
  node's channels hold too little you can spend (after the channel reserve), with how much and what to do.
• A visit's numbers. The visit bar shows what was used, what was prepaid and what is left as credit with
  the shop; Stop says what the visit used. The limit field says the least a shop needs (559 sat for a 546-sat
  ticket) and starts at 1,000.
• Version. The app's version is in the footer and on Setup.
• Faster pages. Found on Nostr, Stream relays and Hashrate show what they last knew at once and ask the
  relays and the hashrate service in the background; repeated reads from the signer within a few seconds are
  answered once. Each response carries a Server-Timing header.

It moves real funds on mainnet and has been tested there with small amounts only. Start with low limits.

What you need first

• StartOS 0.4.0.2 or later.
• Knots BLAKE2b, the node for the Bitcoin BLAKE2b chain.
• Lightning Fork 0.21.4-beta.21.1:2 or later, from its StartOS registry, https://start9.paulscode.com/, with a channel.

Install from the Lightning Stream registry, https://registry.lazarus-xbt.xyz (Marketplace → Switch → Add). StartOS then shows updates as they come; earlier installs update in place. Or sideload the .s9pk for your server (x86_64 or aarch64) under System → Sideload a service. The step-by-step guide is docs/STARTOS.md.

Connecting your Lightning node: Lightning Stream asks Lightning Fork for its own key. Run Lightning Fork's Grant app access task for Lightning Stream to approve it; nothing to paste. The key can only pay, within your spending rules, and you can revoke it in Lightning Fork at any time. Selling needs two invoice-only keys that you make in Lightning Fork and paste on the Sell page, for now.

SHA256SUMS lists the files' checksums.

Lightning Stream 0.2.1 for StartOS

Lightning Stream 0.2.1 for StartOS.

A fix to 0.2.0.

• On Browse, Found on Nostr, a shop reached by its key (such as the demo shop, Lightning Stream
  Genesis) now offers Add this shop. Its list is signed by the key that is its address, so it is the
  shop's own. Before, it offered only Check with the seller, which asks the seller's web address; a
  shop reached by its key has none, so the check failed with a name-lookup error. Adding the shop by its
  key under Sellers worked all along.
• A file that costs less than a shop's smallest ticket can be bought. A Download, or a file opened
  in your player, now lets its first call buy one whole ticket (546 sat, 559 with routing fees, at the
  least) even when the file costs less, such as Big Buck Bunny at Lightning Stream Genesis (about 284
  sat). What the file doesn't use stays as credit with the shop. Before, the call's limit was the
  file's own price, so a buyer with no credit got a raw JSON refusal and nothing was paid. Where the
  wallet names a larger smallest ticket (up to 2,000 sat), the call is made once more with it, and any
  other refusal is now a page in words. Your spending rules still apply to every payment.
• A web-app visit needs a limit of at least 559 sat. A smaller limit opened a visit whose first
  request said the limit was reached with nothing spent. The form now refuses it, says why, and sets
  the limit to 559 sat for you to confirm; what a visit doesn't use stays as credit with the shop.

It moves real funds on mainnet and has been tested there with small amounts only. Start with low limits.

What you need first

• StartOS 0.4.0.2 or later.
• Knots BLAKE2b, the node for the Bitcoin BLAKE2b chain.
• Lightning Fork 0.21.4-beta.21.1:2 or later, from its StartOS registry, https://start9.paulscode.com/, with a channel.

Install from the Lightning Stream registry, https://registry.lazarus-xbt.xyz (Marketplace → Switch → Add). StartOS then shows updates as they come; earlier installs update in place. Or sideload the .s9pk for your server (x86_64 or aarch64) under System → Sideload a service. The step-by-step guide is docs/STARTOS.md.

Connecting your Lightning node: Lightning Stream asks Lightning Fork for its own key. Run Lightning Fork's Grant app access task for Lightning Stream to approve it; nothing to paste. The key can only pay, within your spending rules, and you can revoke it in Lightning Fork at any time. Selling needs two invoice-only keys that you make in Lightning Fork and paste on the Sell page, for now.

SHA256SUMS lists the files' checksums.

Lightning Stream 0.2.0 for StartOS

Lightning Stream 0.2.0 for StartOS.

A public test release. What is new since 0.1.19, in short; the sections below give the details.

In 0.2.0

• Hashrate rental with masked jobs. The Stream Gateway (DATUM-compatible) now comes with the app
  on Umbrel, StartOS and Linux, and a renter's rented hashrate goes through it. Every job is masked
  with a key the gateway holds, so a rented miner can't tell which share is a block and can't
  withhold one. The renter checks each job before its miners get it: a rental whose job can't be
  shown masked ends, and nothing is paid before the first job has been checked. It mines solo, paid
  to your own address, or on Lazarus Pool, which takes jobs masked with your gateway's own key; a pool
  that doesn't is refused.
• Hashrate payments. Both sides prove every share, and a renter pays as the work arrives: you
  never have more paid for and not yet received than a minute of the miner's hashing, or one share,
  one slice and one ticket (546 sat at least), whichever is more, plus any start fee shown on the
  offer. Shares sent again after a link drop still get their verdict, and a hashmaker's difficulty
  requests go no further than the renter.
• Rentals. A start fee asks for 30 pieces of work at most, so a rental with a small piece starts
  before its first payment is due. A seller's listing never offers 0 miners just after a start or a new
  price. A Rent sent twice starts one rental and pays one start fee. Delivery records are shown
  as claims anyone can publish, and a flood of them no longer hides a hashmaker's own. A hashmaker's
  public summary names no renter.
• Wallet limits. The hashrate rental's own limits apply only to the app's renter paying a rented
  miner's work; any other call that names the task "hashrate" is refused (ticket_rental_payer) and
  pays nothing. One task's credit is never spent by another: ticket sessions are per task, so a shop
  may see two sessions from one wallet.
• Paying. Slow routes, channel drops of up to 8 s, a seller's 408, resumes from a byte (with
  If-Range), and stream tickets under load no longer end paid calls or pay twice. An agent's long
  paid call waits for the wallet instead of failing at the MCP. A seller behind a private channel is
  paid through its route hints. A file resumes after a channel outage. Wins are paid in the order
  their sellers' grace ends.
• VPN exits. A tunnel pays about one and a half tickets ahead at most, asks again for a ticket
  refused for a moment, and shows what it has used as it runs.
• The lab checks now require usage times the listed price, to the msat, on both sides for files,
  web apps and VPN tunnels.

Licences

• The Stream Gateway image (xbt-datum-gateway) is CONVOY's datum_gateway (MIT) with Lightning
  Stream's changes. It is linked statically with libsodium (ISC), jansson (MIT), libcurl (curl
  licence), musl (MIT), and two LGPL libraries: libmicrohttpd 1.0.1 (GNU LGPL 2.1 or later) and
  argp-standalone 1.5.0 (GNU Library GPL 2 or later). The image carries each licence and a NOTICE in
  /usr/share/xbt-datum-gateway/. You may rebuild the gateway, or relink it against modified
  versions of those two libraries: this repository holds its complete source, the pinned library
  versions with their sha256 sums, and the script that builds and links it
  (scripts/datum_gateway_build.sh), at the commit the image's tag names. The GitHub release v0.2.0
  carries the exact source tarballs of both libraries that the image was built from, with their
  checksums (SHA256SUMS-datum-gateway-lgpl).

Shops without a web address

• A shop can be reached by its key alone, over an encrypted direct link, with no hostname,
  Cloudflare or port forward. The shop's node vouches for the link, and buyers check that before
  sending anything. Where the two ends can't connect directly, a relay carries the traffic, and it
  never sees what is sent. In private mode a shop uses relays only, so buyers never learn its
  address.
• The relay is built into Stream, off by default. Shops announce the relays they use, and buyers
  choose among them.
• A shop reached only by its key can list web apps and Files from the Sell page.
• The AI address and agents can pay shops reached by key.
• The AI page shows prices for shops reached by key.
• A seller added, updated or removed on the Services page reaches the AI address at once.
• Two AI sellers with the same name are told apart by their shop key or address, so preferring or
  blocking one no longer hits the other.
• After a restart, the AI address finds sellers' models within seconds, instead of answering
  "model not found" for about five minutes.
• A shop saved before its first service is now published on Nostr, so buyers can find it.
• A web app such as Jellyfin works through a relay over a slow path (a VPN, a far-away buyer); the
  wallet keeps a buyer signed in and re-asks a price only when needed.
• A shop reached through relays serves on four keys, each with its own relay connection, so its
  relayed buyers share several connections instead of one.

Sellers' own web apps

• A web app that keeps buyer accounts opens when the buyer's session began on another of the shop's
  routes, or the shop has restarted: the wallet says who it is and asks again, instead of showing a
  raw 403. A buyer who stays anonymous at a shop stays so on all its routes and is told why such a
  page is refused, with nothing charged for that request.
• A seller's whole web app, for example Jellyfin with its full interface, can be sold through
  Stream, paid as it is used, with an account made for each buyer.
• The built-in player is gone. A media server is shared as a web app, and a new Files service
  shares a folder: buyers pay per GB to download a file or open it in their own player.
• On Umbrel, Files shares a folder from the box's Downloads, which the Files app shows; read-only.
• On StartOS, Files can share a folder from File Browser, read-only; File Browser stays optional.
• On StartOS, a shop reached directly through the app can be bought from: Sell asks for a third key,
  link signing (message:write only), so the node vouches for the shop's link. Before, no buyer could
  allow such a shop. A link signing key pasted on a running shop is used within a minute, with no restart.
• Saving the shop with nothing changed no longer restarts it (it cut buyers' sessions), even on a later day.
• A shop switched from being reached directly to a web address no longer keeps serving its direct link.
• Files from File Browser shares only File Browser's own folder, including the files you upload to
  it (File Browser keeps those readable by its own group only; Stream reads them through that group).

Paying

• A download cut short by a channel outage now picks up from the byte it stopped at. If the seller
  has forgotten the session or has no room for more tickets, the wallet opens a fresh session once
  and carries on. It never retries a session the seller faulted or one you stopped, and never pays
  twice for the same bytes. If a seller ignores a byte range and sends the whole file, the wallet
  closes at once; the unread part costs at most what was already on its way.
• A channel outage is no longer taken for a full route. Before, the payments that failed while your
  channels were down halved the tickets your wallet holds with that seller, for this session and the
  next, for up to ten minutes. Now the wallet waits 30 s and pays from prepaid tickets meanwhile, then
  holds as many as before. A route that really is full is still counted as before.
• On a busy wallet, lottery wins are now paid nearest-deadline first. A seller's unpaid wins are
  hurried as soon as it reaches its limit. Every invoice is checked again just before it is sent, so
  none goes out about to expire. A 0.2.0 wallet tells a 0.2.0 seller it can cancel, and gets win
  invoices of up to 180 s, so a busy wallet no longer misses wins. Older wallets and sellers keep
  today's behaviour.
• A seller can now say how long it waits for the next ticket, and the wallet ends its own pause a
  little before that (a tenth of the wait, between 1 s and 3 s), so no ticket is ever paid into an
  answer the seller has already closed. A seller that doesn't say keeps today's behaviour.
• A slow wallet no longer blames a seller whose web server timed out waiting for the wallet's request
  (HTTP 408). Nothing was served or charged: the wallet sends the same request once more, and if it
  times out again, that call alone is refused and the session goes on.
• A file no longer gets cut because the wallet's disk is slow while it pays many sellers. With 50 or
  100 ms added to each of the wallet's disk writes and 20 other sellers' wins queued, the win a seller
  was waiting for was paid after 19 to 30 others, and its file was cut in 9 of 12 runs. It is now paid
  after 1 to 8 others, and the file arrives whole in 12 of 12.
• After the wallet's Lightning node restarts in the middle of a download, a win it could not pay at
  that moment is paid on the next call. The seller used to refuse that call and every later one for
  as long as the session lasted.
• A channel that drops for a moment no longer ends a paid file or answer: the wallet waits up to
  8 s for it to come back, and as long for a route to the seller (after a link further along the way
  was replaced, a node may find none for some seconds), rather than sending a payment that fails. A seller
  the node has no route to for good ends the call with ln_no_route within 8 s counted from after the
  node's checks, and holds up no
  other seller's payments. The route is asked for with the invoice's route hints, so a seller reached through a
  private channel (an LSP's, say) is found as its payment finds it, and waited for the same way; an invoice with
  blinded paths, which the route query does not take, is paid at once, as before. A channel that stay...

Lightning Stream 0.1.19 for StartOS (package revision 1)

A test release for StartOS 0.4. Lightning Stream as one service, the same app as on Umbrel: buy and sell services over Lightning on the Bitcoin BLAKE2b chain, rent hashrate out or in, and let your AI agents pay within the spending rules you sign.

What's new in 0.1.19 (package revision 1): the AI and Agents pages show their addresses correctly (they repeated /v1 and /mcp). Also in 0.1.19: a session busy spending its credit stays open, so long films and rentals no longer strand credit at the seller. New: a local AI address (Services, AI) that any OpenAI-compatible app or agent can use, paid per token, with a key and limit per program. Hashrate rentals survive a short break in the link. A new, calmer look.

It moves real funds on mainnet and has been tested there with small amounts only. Start with low limits.

What you need first

• StartOS 0.4.0.2 or later.
• Knots BLAKE2b, the node for the Bitcoin BLAKE2b chain.
• Lightning Fork 0.21.4-beta.21.1:2 or later, from its StartOS registry, https://start9.paulscode.com/, with a channel.

Install from the Lightning Stream registry, https://registry.lazarus-xbt.xyz (Marketplace → Switch → Add). StartOS then shows updates as they come; earlier installs update in place. Or sideload the .s9pk for your server (x86_64 or aarch64) under System → Sideload a service. The step-by-step guide is docs/STARTOS.md.

Connecting your Lightning node: Lightning Stream asks Lightning Fork for its own key. Run Lightning Fork's Grant app access task for Lightning Stream to approve it; nothing to paste. The key can only pay, within your spending rules, and you can revoke it in Lightning Fork at any time. Selling needs two invoice-only keys that you make in Lightning Fork and paste on the Sell page, for now.

SHA256SUMS lists the files' checksums.

Lightning Stream 0.1.19 for StartOS

A test release for StartOS 0.4. Lightning Stream as one service, the same app as on Umbrel: buy and sell services over Lightning on the Bitcoin BLAKE2b chain, rent hashrate out or in, and let your AI agents pay within the spending rules you sign.

What's new in 0.1.19: a session busy spending its credit stays open, so long films and rentals no longer strand credit at the seller. New: a local AI address (Services, AI) that any OpenAI-compatible app or agent can use, paid per token, with a key and limit per program. Hashrate rentals survive a short break in the link. A new, calmer look.

It moves real funds on mainnet and has been tested there with small amounts only. Start with low limits.

What you need first

• StartOS 0.4.0.2 or later.
• Knots BLAKE2b, the node for the Bitcoin BLAKE2b chain.
• Lightning Fork 0.21.4-beta.21.1:2 or later, from its StartOS registry, https://start9.paulscode.com/, with a channel.

Install from the Lightning Stream registry, https://registry.lazarus-xbt.xyz (Marketplace → Switch → Add). StartOS then shows updates as they come; earlier installs update in place. Or sideload the .s9pk for your server (x86_64 or aarch64) under System → Sideload a service. The step-by-step guide is docs/STARTOS.md.

Connecting your Lightning node: Lightning Stream asks Lightning Fork for its own key. Run Lightning Fork's Grant app access task for Lightning Stream to approve it; nothing to paste. The key can only pay, within your spending rules, and you can revoke it in Lightning Fork at any time. Selling needs two invoice-only keys that you make in Lightning Fork and paste on the Sell page, for now.

SHA256SUMS lists the files' checksums.

Lightning Stream for StartOS 0.1.18 (test release)

A test release for StartOS 0.4. Lightning Stream as one service, the same app as on Umbrel: buy and sell services over Lightning on the Bitcoin BLAKE2b chain, rent hashrate out or in, and let your AI agents pay within the spending rules you sign.

What's new in 0.1.18: closing or pausing the player stops the paying, and a film is bought at most 4 MiB at a time. With the starter rules a buyer can play a film and then ask the AI of the same shop straight away. Live connections show what a stream has used as it plays.

It moves real funds on mainnet and has been tested there with small amounts only. Start with low limits.

What you need first

• StartOS 0.4.0.2 or later.
• Knots BLAKE2b, the node for the Bitcoin BLAKE2b chain.
• Lightning Fork 0.21.4-beta.21.1:2 or later, from its StartOS registry, https://start9.paulscode.com/, with a channel.

Install from the Lightning Stream registry, https://registry.lazarus-xbt.xyz (Marketplace → Switch → Add). StartOS then shows updates as they come; earlier installs update in place. Or sideload the .s9pk for your server (x86_64 or aarch64) under System → Sideload a service. The step-by-step guide is docs/STARTOS.md.

Connecting your Lightning node: Lightning Stream asks Lightning Fork for its own key. Run Lightning Fork's Grant app access task for Lightning Stream to approve it; nothing to paste. The key can only pay, within your spending rules, and you can revoke it in Lightning Fork at any time. Selling needs two invoice-only keys that you make in Lightning Fork and paste on the Sell page, for now.

SHA256SUMS lists the files' checksums.