My next piece that I'm finalizing for #FeatherPub is a control structure.
I'm envisioning the control structure as kind of a parallel structure to the concepts of "actor" and "attributed to." It says "who do I talk to about the object" and can also provide information about "who has permission to act upon the object."
It may or may not be the actor of an action. For instance a server may have an endpoint for flags that has nothing to do with the actor.
I think I can get the first draft of what I'm thinking for #FeatherPub out in the next… two weeks. It will probably be sans tests for the moment, but my goal is to have a set of gherkin .feature files to go along with it by the time I make significant headway.
For the sake of my own sanity I am not going to develop the logic behind the steps in public (that'll go into my personal project), but I'll at least release the feature files and base spec docs in public.
What I'm kind of thinking for #FeatherPub is to define one or more streams.
So the inbox is a stream, but there are additional streams that may have different semantics, at least one of which (defined in the spec) is essentially "posts only."
That way I can preserve the semantics of inbox but also define the capacity to read the relevant parts of the feed, and separately define what goes into one versus the other.
Thinking out loud: part of my thinking in how I am approaching #FeatherPub is what I started thinking of as the "boids model" of federated software development.
"But Hrefna, I sure as hell didn't hear about the 'boids model' in my SE classes"
Yes, this is just kind of my own colloquial thinking about it.
For those who are unaware, boids is an artificial life simulator based around the flocking behavior of birds. The idea is that we can simulate general flocking with a few basic rules.
I want to implement some control/system messages. Ack. Nack. Operation. I'll probably publish an update with what I'm thinking here once I get a little farther.
This is very "not RDF" in how I'm thinking of structuring it, but that's okay.
Implement the rest of the objects. This will also probably be posted
Start implementing activity flows sans API layer off of just a queue for my own part
Okay, here's all of the pieces that are currently required (it will get better before I move forward, but part of my goal in doing all of this is to figure out what parts are necessary and which are not.
Define an interface for the object. Have it extend one of the base annotations (Any, Base, etc).
Define a record that implements the interface in (1).
On the interface put a @'JsonDeserialize annotation with as of the record and using=the deserializer.
This is a living document that will reflect what I decide to put into the parser, so things aren't stable until much later in the process, but I want the document to be ready to evolve.
The goal is to be almost entirely compatible with the implementations of mastodon and mobilizon in terms of objects, and so most elements will reflect similar decisions.