Skip to content
This repository was archived by the owner on Dec 19, 2025. It is now read-only.

Bump 0.0.10#64

Merged
DanGould merged 1 commit intopayjoin:mainfrom
DanGould:bump-0.0.10
Mar 17, 2025
Merged

Bump 0.0.10#64
DanGould merged 1 commit intopayjoin:mainfrom
DanGould:bump-0.0.10

Conversation

@DanGould
Copy link
Copy Markdown
Collaborator

Enable opt-in Gateway reachability for BIP 77

The BIP 77 Draft imagines clients reach one another over a "mailbox" store-and-forward server through OHTTP Relays. In order for Relays to reach those mailbox servers without being pre-defined, this release includes support for an opt-in mechanism based on RFC 9540's Oblivious Gateway discovery mechanism augmented with an allowed_purposes parameter that may specify the BIP 77 mailbox as a specific service.

This was activated by implementing probing functionality that caches allowed_purposes responses to prevent this Relay from being party to denial of service attacks where a client might spam requests to Gateways that do not support an allowed purpose.


cargo publish --dry-run succeeds
as does test_local with a patched ohttp-relay in payjoin-test-utils: ohttp-relay = { git = "https://github.com/dangould/ohttp-relay.git", rev = "73d189689248080708ca8605833c4227edb35584", version = "0.0.10", features = ["_test-util"] }

Enable opt-in Gateway reachability for BIP 77

The [BIP 77 Draft](bitcoin/bips#1483) imagines
clients reach one another over a "mailbox" store-and-forward server
through OHTTP Relays. In order for Relays to reach those mailbox servers
without being pre-defined, this release includes support for an opt-in
mechanism based on RFC 9540's Oblivious Gateway discovery mechanism
augmented with an `allowed_purposes` parameter that may specify the
BIP 77 mailbox as a specific service.

This was activated by implementing probing functionality that caches
`allowed_purposes` responses to prevent this Relay from being party to
denial of service attacks where a client might spam requests to Gateways
that do not support an allowed purpose.
Copy link
Copy Markdown
Contributor

@nothingmuch nothingmuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a binary the changes are backwards compatible, the same configuration options should work, the same endpoints too, but new ones are possible, but it's also a significant change that may require different decisions/considerations for operators... not sure what that means from semver?

as a library, this is API breaking, but only payjoin-test-utils cares, so again not sure what that means

ACK for changelog etc, undecided re version number but 0.0.x is often not yet committing to anything either so not sure

@DanGould
Copy link
Copy Markdown
Collaborator Author

I was using 0.0.x for "anything goes, don't rely on api stability" with the intention to release a 0.1.x once we've committed to a feature set and feel comfortable enough with our testing to call it "beta," I reckon when BIP 77 is merged.

I can understand an argument for 0.1.0 just for breaking, but I figured it'd signal some movement toward stability too. Since you don't have a strong opposition to 0.0.10, I'm gonna go ahead and merge and release and commit to our next breaking change being 0.1.0. If you're on the fence now, I reckon the next set of breaking changes should push you over the edge. And if they don't come, the next release should be one that improves stability.

@nothingmuch
Copy link
Copy Markdown
Contributor

I'm not on the fence, 0.0.x being yolo territory makes a lot of sense, just wanted to point out that the pub fn api did change to require a new argument (certificate root store in #63)

@DanGould DanGould merged commit 5d830fd into payjoin:main Mar 17, 2025
5 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants