Hello! - Knowledge Sharing

[BanjoFox]

Hi there!

While looking for existing resources for my project (Aardwolf, also on GitHub), and I found this. It is very exciting to see other people working on ActivityPub for rust :)

I also just saw this Gist:
An attempt at representing ActivityPub in Rust
https://gist.github.com/wezm/65e416619f7c4b1e7a510b169426068d

Perhaps we can all share ideas :)

Cheers!

Banjo

[lo48576]

Hello.
I'm also excited to know Rustaceans interested in ActivityPub!
Sorry for my poor English.

JSON views

I have chosen to implement "views" over (around?) raw json objects, not to implement structs to represent ActivityPub objects directly (like your link https://gist.github.com/wezm/65e416619f7c4b1e7a510b169426068d#file-activitypub-rs-L134 does).
(Example: https://github.com/lo48576/rustivitypub/blob/0660d96c713420d4875d540161aa8e7e5e9e78fa/rustivitypub/src/document/view/link.rs)
The reasons is below:

• ActivityPub object can have extra fields and may not have some fields.
  • Application (or extensions?) would want them.
• ActivityPub object types use inheritance heavily, but idiomatic Rust cannot treat it naturally.
  • gtk-rs's way is a possible approach, but I feel it is not beautiful (and not idiomatic Rust).
• There's so many ActivityPub (ActivityStreams) types and I don't want to translate them all into Rust's types.
  • It is too painful to write boilerplate codes like this many times...
• DB backend library may want to store raw JSON file, not deserialized Rust object.

Goals of rustivitypub

I want my ActivityPub library to do:

• Define primitive types (URL, IRI, media type, and so on...)
• Provide views for complex types.
  • A view should return values with a correct primitive type for the given field name.
    • For example, image.media_type() should return Result<MediaType> or something like that (Result<MediaTypeView>?).
    • With this design, schema error and type error will happen at access to properties, not at parsing (deserializing). I think it is no problem, because Rust has powerful error handling system and errors would not be ignored.
    • Type check will happen at every access to properties, but I don't think it will be big overhead, because frequently used properties would cached as local variable.
• Provide way to easily create ActivityPub objects.
  • I think it would be possible with builder pattern and mutation through view types.
• Provide DB-backend-agnostic and web-frontend-agnostic middleware
  • I wanted the library to be usable with sqlite, MySQL, json files, etc...

My future plan

I was reckless to write this library without no preparation.
I will rewrite almost all of the codes (but the core design might not change a lot).

I am currently busy with my private tasks (at least until Feb 2018), but preparing libraries to support writing this (opaque_typedef is one of them, it will make it easy to implement wrapper types).

As you can see in link.rs and property.rs, current codes are full of boilerplates and I'm tired of writing such codes.
I feel that I should write them with macro or automated code generation.

One possible way:

declare_properties! {
    ("href", href, Iri),
    ("hreflang", hreflang, LanguageTag),
    ("mediaType", media_type, MediaType),
    ...
}
declare_views! {
    LinkView(href, hreflang, media_type, ...),
    ...
}

I will implement things above after I get free, but I am not sure this is good direction.
I want to see many different designs of people and compare them.

[BanjoFox]

I would say that your English is pretty good :)
Growing up we had a lot of foreign exchange students so I have learned how to interact with non-native speakers.

My project specifically is here:
https://github.com/BanjoFox/Aardwolf/

So far it looks as though you have a pretty good plan in place, and I would like to spread more word about your project.

Have you seen the ActivityPub implementations test suite?
https://test.activitypub.rocks/

[lo48576]

Yes, I know it but I'd never used it.
I am writing codes by referring to W3C specs, and I'm going to use test suite when the implementation become practical.

When I am unsure about some point (especially at data schema), I observe Mastodon's response by curl -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' https://mastodon.example.com/@exampleuser | jq . ;-)