## Generated by Codox

# Dog-and-duck 0.1.0-SNAPSHOT

# dog-and-duck.quack.quack

Validator for ActivityPub objects: if it walks like a duck, and it quacks like a duck…

**NOTE THAT the ActivityPub spec says

> Servers SHOULD validate the content they receive to avoid content spoofing attacks

but in practice ActivityPub content collected in the wild bears only a hazy relationship to the spec, so this is difficult. I suspect that I may have to implement a `*strict*` dynamic variable, so that users can toggle some checks off.

### activity?

`(activity? x)``(activity? x severity)`

`true` iff `x` quacks like an activity, else false.

view source

### actor-or-uri?

`(actor-or-uri? x)`

`true` if `x` is either a URI or an actor.

TODO: I need to decide about whether to reify referenced objects before validation or after. After reification, every reference to an actor must be to an actor object, but before, may only be to a URI pointing to one.

view source

### actor?

`(actor? x)``(actor? x severity)`

Returns `true` if `x` quacks like an actor, else false.

view source

### collection-page?

`(collection-page? x)`

`true` iff `x` quacks like a page in a paged collection, else `false`.

view source

### collection?

`(collection? x object-type)``(collection? x)`

`true` iff `x` quacks like a collection of type `object-type`, else `false`.

With one argument, will recognise plain collections and ordered collections, but (currently) not collection pages.

view source

### link-or-uri?

`(link-or-uri? x)`

`true` iff `x` is either a URI or a link, else false.

There are several points in the specification where e.g. the `:image` property (if present) may be either a link or a URI.

view source

### link?

`(link? x)``(link? x severity)`

`true` iff `x` quacks like a link, else false.

view source

### object?

`(object? x)``(object? x severity)`

Returns `true` iff `x` is recognisably an ActivityStreams object.

NOTE THAT The ActivityStreams spec says:

> All properties are optional (including the id and type)

But we are just not having that, because otherwise we’re flying blind. We shall reject objects lacking at least `:type`. Missing `:id` keys are tolerable because they represent transient objects, which we expect to handle.

NOTE THAT The ActivityPub spec says

> Implementers SHOULD include the ActivityPub context in their object definitions

but in samples found in the wild they typically don’t.

view source

### ordered-collection-page?

`(ordered-collection-page? x)`

`true` iff `x` quacks like a page in an ordered paged collection, else `false`.

view source

### ordered-collection?

`(ordered-collection? x)`

`true` iff `x` quacks like an ordered collection, else `false`.

view source

### persistent-object?

`(persistent-object? x)``(persistent-object? x severity)`

`true` iff `x` is a persistent object.

Transient objects in ActivityPub are not required to have an `id` key, but persistent ones must have a key, and it must be an IRI (but normally a URI).

view source

### unordered-collection?

`(unordered-collection? x)`

`true` iff `x` quacks like an unordered collection, else `false`.

view source