GitLab

Here is an abbreviated version of a discussion in chat, portions copied here:

What's the difference between Proposals and Intents ?

A Proposal is a way to publish an Intent. Actually, often 2 Intents, if you want to say what you would like to receive for what you are offering, or vice versa for a request. But mostly the first. The model is somewhat complex because the thinking was that for some intents, you would want to publish into different places, etc. - anyhow publish more than once.

I like this seperation, means you can create one intent but pubish in different groups with different reciprocity arrangements or currencies, and also if your proposal expires you can republish one which still points to same intent.

and one reusable intent would be important if your intent is part of a process for example

But u can still create an intent without proposing anything back right? In that way it would be a plain intent

Yes, not every intent will have a proposal, if you publish it differently (we can think of examples) - but the proposal is where things like dates of publication are.

And be aware, we have tried a lot of the VF model in software, but not intents or proposals.

So the intent is the object and proposal the activity, if we compare with AP?

Well, not totally because you also need something to hold the intents together, so the Proposal becomes more than an Activity maybe. I pictured we use Offer and create another activity called Request, and the object would be the Proposla with all the stuff under it.

So with the intent nested as another object in the proposal object?

Yes, we'd still have them be separate AP objects with their own ids / canonical urls, but they can be nested

I guess it depends how "correct" we want to be vs how easy we want to make it for other apps to support offers/requests. Most implementations seem to mostly stick with Create.

my original thought was to totally stick with Create (and Update, Delete), and make every VF thing an object of those - that was to have the least impact on existing AP/AS specs - but Chris B was thinking that the "edges" in VF should basically be activities - which they probably are conceptually

Yeah that may be easier than trying to map activities (and add missing ones)

In that case, wouldn't Propose be the activity

Yes - but Offer is already there... and Offer / Request are really better terms

i'm not tied to one or the other personally, don't feel like I have the experience with the AP culture etc. maybe one reason to have them all objects is that there is something (a SHOULD?) in the spec that if something arrives without an activity, it gets wrapped in a Create

We create the culture 😉 But yeah, there's lots in the specs that was based on assumptions and lots of implementors are just sticking with what interops with Mastodon

my thinking is to stay as "pure" spec as we can - and then probably have to write some extra code to make it actually interoperable with mastodon etc ?? but I don't actually know what that means in practice except there certainly are people who would appreciate a "pure" spec AP although it is also true that the list of AS activity types is kind of a mish-mash, so already you can see that there were a lot of different opinions accommodated with kind of a crazy outcome (imo)

Well, we don't want to be spammy (and use more resources) and send double activities. While we maybe (to be tested) can send a Create that contains an object that's is multiple types (like ['Proposal', 'Note']) so apps that don't recognise our objects can fallback to title/description/etc

i can see some value in an offer showing up as a note, but i can also see that it will be fairly limited, and we could also just let it get ignored unless the installation supports VF / economic stuff

Maybe as Link would be better. Not many support yet IIRC, but makes for cleaner and more minimal fallback.

another advantage to using just create/update/delete - we don't have to write an extension of AP or AS, because there will be no new terms besides AP/AS and VF

might be some extra references, like if the vf stuff all become subclasses of as:Object

They don't need to be subclasses if they also share an AS type

Yeah, and Place for spatialThing, and maybe others that fit more for each

Re. link: The AP module prepares the json for activity/object, stores it in DB for outbox, and then pushes to inboxes. So the url exists when instances receive an activity (and many implementations will fetch it to cross check validity)