Bark 版本历史 - 6 个版本
Bark 作者: ForgeSworn
Bark 版本历史 - 6 个版本
小心旧版本!显示这些版本是为了测试和参考目的。您应该始终使用附加组件的最新版本。
最新版本
版本 1.3.13
发布于 2026年9月17日 - 327.12 KB适用于 firefox 140.0 及更高版本, android 142.0 及更高版本- A Heartwood that does not answer the connect-time capability probe within
five seconds is no longer written off as "not a Heartwood". New signer
firmware (v0.18.0-beta.9) asks the owner to approve identity listing once, on
the device, and that press can take longer than the probe waits. Bark now
keeps listening in the background for up to 45 seconds, shows "Approve on
your Heartwood to show personas" where the persona section goes, and enables
Heartwood mode as soon as the answer arrives. A probe that finally times out
is no longer remembered as a negative verdict, so the next popup or
reconnect tries again. An explicit refusal still falls back immediately, as
before.
源代码遵循 MIT 许可证 发布
- A Heartwood that does not answer the connect-time capability probe within
较早版本
版本 1.3.11
发布于 2026年9月9日 - 326.71 KB适用于 firefox 140.0 及更高版本, android 142.0 及更高版本- Heartwood instances hand off to Sapwood when the signer stops answering. A
failed sign test, or a connection that stays lost, now shows "Unlock in
Sapwood": Bark only speaks NIP-46 and a locked signer never answers it, so
the unlock has to happen in Sapwood (USB or relay delivery) before Bark can
sign again.
源代码遵循 MIT 许可证 发布
- Heartwood instances hand off to Sapwood when the signer stops answering. A
版本 1.3.10
发布于 2026年9月9日 - 326.16 KB适用于 firefox 140.0 及更高版本, android 142.0 及更高版本- The popup no longer calls
window.confirm()when removing a signer or
resetting policies. Chromium shows those dialogs app-modal, so a popup that
closed while one was up (any focus loss closes a toolbar popup on macOS)
left an orphaned modal that froze every extension's toolbar popup until it
was found and dismissed. Both confirmations now use an inline<dialog>
that lives and dies with the popup.
源代码遵循 MIT 许可证 发布
- The popup no longer calls
版本 1.3.9
发布于 2026年8月13日 - 325.65 KB适用于 firefox 140.0 及更高版本, android 142.0 及更高版本- Firefox for Android support. The Firefox build now declares
browser_specific_settings.gecko_android(minimum 142, two releases above the
desktop floor becausedata_collection_permissionsreached Android later), so
the AMO listing installs on Android instead of being treated as desktop-only.
This is the only mobile route for Bark: Chromium on Android compiles out the
extensions subsystem, so Vanadium on GrapheneOS and every other
Chromium-derived Android browser cannot run it. See docs/mobile.md
for the Cambium and direct-NIP-46 alternatives.
- Approvals no longer fail outright on mobile. Firefox for Android implements no
windowsAPI at all, so every ask-policy request would have been denied with
"Could not open approval window". The approval surface now falls back to a
foreground tab: dismissing it denies, "Review in Bark" foregrounds it, and the
background closes it once the request settles. Desktop keeps the popup window. - The popup and approval pages lay out against the device width rather than the
980px default mobile viewport. No change to desktop rendering.
Verified on a Pixel 10 Pro XL running GrapheneOS with Firefox for Android
153.0.4: provider injection, the approval tab (allow once, trust site, deny,
dismiss-to-deny, queued approvals), and signing after the event page suspends.源代码遵循 MIT 许可证 发布
- Firefox for Android support. The Firefox build now declares
版本 1.3.7
发布于 2026年8月9日 - 324.99 KB适用于 firefox 140.0 及更高版本- The nostrconnect pairing QR now carries a requested-permission bundle:
read pubkey, NIP-04/NIP-44 encryption, and the common event kinds —
including the V4V gated kinds 27117 and 30808 — mirroring Sapwood's kind
registry. The signer shows the whole surface at pairing and the human
approves once, instead of discovering an unlisted kind mid-flow and adding
a manual grant later. The popup explains the bundle before the QR is
generated.
源代码遵循 MIT 许可证 发布
- The nostrconnect pairing QR now carries a requested-permission bundle:
版本 1.3.4
发布于 2026年7月18日 - 295.27 KB适用于 firefox 140.0 及更高版本"The message port closed before a response was received" is now treated
as a service-worker wake-up error and retried, matching the other
wake-up wordings. Previously the first request after the worker idled
out could fail with this error instead of retrying.源代码遵循 MIT 许可证 发布