Other Implementation of ActivityStreams

[benrick]

Thanks to a couple of toots, I've been alerted of someone working on ActivityPub in dotnet that's not open yet and also this ActivityStreams implementation.

https://github.com/KristofferStrube/ActivityStreams

Possibly a project that we may be able to collaborate on or use a package he creates.

[kirkbrauer]

This is really intriguing @benrick. It looks like this implementation is almost exactly what I was thinking of for implementing the ActivityStreams in .NET. He even has the JSON Converters setup, which would have to be the next step for us after the basic models.

We should look at either using this as a package, or maybe merging in this project so it can evolve alongside Smilodon.

[KristofferStrube]

My goal would be to have it as its own package so that it can potentially be used by multiple projects. But it is also important for me to have it be usable by other projects i.e. by making it extendable.

[kirkbrauer]

@KristofferStrube I see. I was working on a prototype as well, they way I tackled this was by using a series of interfaces and base classes, which allows for those to exist specifically in the ActivityPub context. Obviously, that might be messy, but it's a bit more C-sharpy in IMHO. Since we're focused on being an ActivityPub server, having those as properties is probably better for that specific use case.

[KristofferStrube]

Yeah, that's kinda the problem. I can't seem to find a way to both have ActivityStreams as its own thing and have ActivityPub properties as actual properties. I might just change the project to support all the models/properties in ActivityPub as a standard.

[kirkbrauer]

For us, I was thinking about having three projects: Smilodon.JsonLd, Smilodon.ActivityStreams, and Smilodon.ActivityPub. Each would expose base interfaces and reference classes, but Smilodon.ActivityPub would be the top-level package that we would actually use in the server implementation. This would give us the following base classes: JsonLdObject -> ActivityStreamsObject -> ActivityPubObject. We would use ActivityPubObject in most contexts. One potential issue I see in your naming convention is using the class name Object, which is used in the System library and could cause a lot of import conflicts for users.

[kirkbrauer]

With regards to JSON-LD, I have created all the base models, I can make a PR on your repo if you want me to. Obviously, we can't handle all potential JSON-LD documents, but if we can handle all the specification properties in the normalized format, we should be able to consume any potential JSON-LD Context Definition that comes our way by the means of ActivityStreams/ActivityPub.

[benrick]

That's exactly what we were intending to do with ours, so that's prefect!