[bug] Unable to interact with ktistec users

[LindsayZhou]

Describe the bug with a clear and concise description of what the bug is.

I send a follow request to a ktistec user, and he didn't receive that.

Ktistec requires (created) http signature header.

Gts' implemetation doesn't include it:

gotosocial/internal/transport/signing.go

Lines 28 to 29 in b7c629a

	getHeaders = []string{httpsig.RequestTarget, "host", "date"}
	postHeaders = []string{httpsig.RequestTarget, "host", "date", "digest"}

Mastodon attempts to use the (created) header first, fallback to the Date header if not present.

The spec draft recommends using the created signature parameter (not required)

Log

From Gts server:
timestamp="21/04/2024 20:46:22.302" func=workers.(*clientAPI).CreateFollowReq level=ERROR requestID=v9vv204f040018tk485g msg="error federating follow request: Follow: error sending activity *typefollow.ActivityStreamsFollow via outbox https://moe.reisen/users/lindsay/outbox: func1: error delivering to https://qaq.land/actors/qaq/inbox: deliver: POST request to https://qaq.land/actors/qaq/inbox failed: status=\"400 Bad Request\" body=\"{\"msg\":\"can't be verified\"}\""

From Ktistec server:

INFO - verification failed: (created) header must be signed
WARN - Ktistec::Open.open? - Does not exist [404]: https://moe.reisen/users/lindsay/follow/<signature_string>

What's your GoToSocial Version?

v0.15.0

GoToSocial Arch

x86_64 Binary

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

No response

Anything else we need to know?

No response

[tsmethurst]

Thanks! I'll see if we can rejig our signature without breaking compatibility for anything else. Didn't realize (created) was recommended.

[daenney]

It's recommended, not required, so any implementation that aims to correctly implement the spec should accept a signature without that field.

RECOMMENDED. The created field expresses when the signature was
created. The value MUST be a Unix timestamp integer value. A
signature with a created timestamp value that is in the future MUST
NOT be processed. Using a Unix timestamp simplifies processing and
avoids timezone management required by specifications such as
RFC3339. Subsecond precision is not supported. This value is useful
when clients are not capable of controlling the Date HTTP Header
such as when operating in certain web browser environments.

The last bit is kinda crucial:

This value is useful when clients are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments.

GtS is able to control that header just fine, and we do. It's hopefully not too much faff to add the attribute on our side, but implementing a stricter requirement than the spec is a bug, at least from an interoperability point of view.