go-fed / activity Goto Github PK

Use golang's proposed semantic versioning package management for the initial release.

Right now, with the usage of vocab.ObjectType and cousins, they are overly-specific. Hard for other semantic layers and serialization/deserialization layer combinations to plug in, besides the provided vocab or stream packages.

Broken out of issue #48.

*url.URL is typically used while current use of url.URL is atypical.

Broken off from #9

Add support for HTTP signatures:
https://tools.ietf.org/html/draft-cavage-http-signatures-09

Which use this Vocabulary:
https://web-payments.org/specs/source/vocabs/security.html

And until w3c/activitystreams#477 is fixed, this means we will also need to specify this context ourselves, in addition to the AS one.

This is where I will post unofficial implementation reports of this library generated by the thin server wrapper around this library at https://github.com/go-fed/report.

Since I am tackling the implementation report one step at a time, as it is very comprehensive, I wanted to provide insight along the way.

Once an official version is available, I will close this issue and refer to that in the README.

§5.8

Adhere to §5.

ErrObjectRequired and ErrTargetRequired no longer need to be exposed.

Both go build and go install fail for streams and vocab on a Raspberry Pi 3 due to running out of memory. (I can get specifics later today if needed; the pi is so upset with me it's no longer responding to ssh)

I understand why: the packages are huge, with good reason. A simple fix would potentially be to offer releases for major/minor versions.

(users can also compile on a better machine with env GOOS=linux GOARCH=arm go build and then copy the binary)

As outlined in 7.1.2

When going through the implementation report, it seems like my choice to favor adding the full object if able to other collections, objects, etc. is probably not the correct one for consistency reasons. Implementations won't want to manage an object and its value within a collection if the full object is added within the collection.

Go back through and prefer IRIs instead.

Since go 1.10, go vet is now default run on go test. Make sure everything passes go vet.

I am not sure what, if any, authentication schemes are in place. Or if it is simply to have a server verify (via HTTP AP GET) that the Update or Create object is indeed truly at the origin, and therefore the entire Activity message delivered is trustworthy.

In practice this may just be deferred to the library user, who must satisfy some sort of interface that is TBD.

Technically object can be an IRI. But in practice, unsure if the ActivityPub implementations support this.

Right now it provides no out of the box functionality.

The 'actor' on the 'Undo' MUST be the same as the 'actor' on the Activity being undone, and the client application is responsible for enforcing this.

Currently:

• DoesNotDeliverNondeliverable
• SetsLocationHeader

• Mention that this library follows semantic versioning.
• Have a patch notes document
• Create and link to a CONTRIBUTING doc
• Add section How can I get help? which links to the relevant section in the CONTRIBUTING file
• Include links to unofficial or official implementation reports.

Hey,

I had a look into vocab.go. On my machine it adds about 40s of compile time.

I have a couple of questions and ideas how to reduce the file size, but Im not exactly sure how they impact the compile time actually.

Why are there interfaces for all the types? Are there more than one implementation for them?

What about adding more generic interfaces, like Serializer and Deserializer?

e.g.

type AltitudeTrait interface {
	IsAltitude() (ok bool)
	GetAltitude() (v float64)
	SetAltitude(v float64)
	IsAltitudeIRI() (ok bool)
	GetAltitudeIRI() (v *url.URL)
	SetAltitudeIRI(v *url.URL)
}

What about dumping all the types that can be represented as an Object (like Note, Page)?

HTTP caching mechanisms [RFC7234] SHOULD be respected when appropriate, both when receiving responses from other servers as well as sending responses to other servers.

Client can provide a caching solution, lib would just use it.

Uncovered while examining implementation report.

As specified in §6.4

This will allow client libraries to lock data and prevent race conditions as appropriate.

Particularly nontrivial since this is not exposed in encoding/json, and is buried in the std lib private scanner.

As required in the spec and detected in the implementation report

Hey,

can you generate multiple smaller files than rather than having a huge one? Github wont render it and my IDE goland would go totally crazy when Id try to open it.

Currently all requests sent via dereference use no credentials.

Have New functions just set the single passed-in SocialApp, FederateApp, SocialFederateApp to the correct federator fields.

Something like

func Serve(c context.Context, w http.ResponseWriter, r *http.Request, s vocab.Serializer) (handled bool, err error) {
  //...
}

This is a catch-all bug for things I am fixing related to generating the implementation report for this library at https://test.activitypub.rocks. I haven't pushed the commits yet so I wanted to create this for visibility.

These fixes are API compatible with the 0.1.0 release:

• Better header detection for determining whether a request is an ActivityPub request.
• Outbox activities are now Set in addition to the outbox OrderedCollection itself.
• A mixup with handling bcc/bto is no more, preventing a panic.

These commits aren't yet pushed to this repo; expect them within 24 hours.