Notices by infinite love ⴳ (trwnh@mastodon.social)

@cwebber nobody cared who i was until i took off the masc

@silverpill @steve regarding as:result itself there are some other ideas that have come up in past years so good to discuss those in a more focused thread:

- either marking activities as the "result of" (maybe "in response to"?) another activity could update the other activity to refer to the later activities, or the "result of" property is defined as a @\reverse property of as:result
- quote stamps currently use result for the stamp itself, not a Create activity for it

@silverpill @steve the type information is largely unnecessary and shouldn't factor into handling CRUD, especially if the objects are managed by the client. the authorization/trust model for which activities are allowed to CRUD which objects is important but can be something other than fe34 (such as an explicit access control policy or authorization resource). also multiple CRUD mechanisms may be in use.

@silverpill @steve so we might need to recommend that these "side effect" activities in as:result SHOULD have fragment identifiers, to be able to refer to them later? or do we intend to never refer to them later? we could say they're transient activities so don't need to be referred to later (only processed in-order).

lastly as:result itself maybe doesn't have these semantics defined, so should a subproperty or different property be used, or do we skip non-CRUD results?

@silverpill @steve also the server's main responsibility being publishing and therefore needing to mint an identifier for the top level activity, we should ask if the server is expected to assign any inner ids as well? assigning ids changes the graph so it's not clear cut. <how does the server know *which* ids to assign and which ones not to?> is an open question (and maybe blank node identifiers are actually in practice required to avoid ambiguity?)

@silverpill @steve it sounds like you're describing an "AP server" whose primary functionality is not "publish activities" but rather "manage CRUD for objects and Add/Remove for collections", by taking the AP "side effects" for Create/Update/Delete/Add/Remove and and saying the outbox should also check as:result.

which is cool but should probably be disambiguated.

@silverpill @steve typically i've taken a view similar to IFTTT -- the activities describe things that happen, probably already happened. one or more listeners can do whatever they want with that information. CRUD is boring to me and i would rather do that with HTTP (POST/GET/PUT/DELETE); the more interesting activities are things like Listen (scrobbles) or Arrive (checkins) or Question (stackoverflow) or so on.

@silverpill @steve this actually raises an interesting question about "side effects" and where they live. in the AP spec it's rather muddled and i've talked before about the issue of "activities as content/notifications vs activities as procedure calls". i personally err toward having no side effects, which i think were kind of a mistake for the reason you bring up (generic servers can never be aware of extended side effects).

@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest

@silverpill @raphael @mariusor

> neither is it an interesting concept

> interoperates with the rest of the network

look, we clearly have different goals here. your goal is to interoperate with the mastodon network. my goal is to publish activities to my website. mastodon doesn't even support all the activities defined in AS2-Vocab. a generic server supports *any* activity, even those not defined by AS2. the network i want to interoperate with isn't mastodon, it's the web.

@cwebber the prove-your-phone-id and ios/android requirement is precisely why i don't use signal 🙃

i really hate how certain parts of society require a phone number at all. i have a google voice number from like 17 or 18 years ago at this point that i got before i even had a phone. i would prefer not to use it, but unfortunately my medical provider requires sms 2fa and only supports sms 2fa. banks are also notorious for this.

@eyeinthesky @thisismissem @smallcircles i would use as:result for this -- the *result* when you Accept the Like activity is to Add it to the likes collection... if you care about that level of detail. most people only care about the Like. maybe even less than that! (synthesizing a statement such as :bob :likes :this.)

@evan @gugurumbe @cwebber @kopper @hongminhee only for terms defined in AS2, though?

if the activitystreams context is missing in an application/activity+json document, then you MUST assume/inject it. this means you can't redefine "actor" to mean "actor in a movie".

otherwise, you don't have to augment the context with anything else. "https://w3id.org/security#publicKey" is a valid property name. the proposal is to not augment the normative context where possible. no parsing context if there is no context

@raphael @silverpill @hongminhee @mariusor what is far more powerful is drawing *equivalences* between values. you might say every lemmy:Community is also always as:Group, but not every as:Group is always a lemmy:Community. in this case we are basically saying lemmy:Community is rdfs:subClassOf as:Group.

separately we might say every as:Group is also a vcard:Group, and vice versa -- that might make them owl:equivalentClass, but that doesn't mean the "activity model" and "vcard model" are equal!

@raphael @silverpill @hongminhee @mariusor example: if you took lemmy's use of as:Group you might assume that every as:Group is a lemmy-style "community" and that it always produces 1b12-style Announce activities, and that "Announce" means how they use it and not its actual definition.

now if lemmy had used their own vocabulary, it might be easier to understand that "this is a lemmy-style community".

the activity processing model shouldn't care what lemmy properties are used.

@raphael @silverpill @hongminhee @mariusor most often the trouble i see is with ignoring the fact that everyone is using the same terms with different meanings, and pretending that we all agree when we actually do not.

the second most common issue i see is with the complete lack of any guarantees beyond "this thing is probably an activity" (which even that small bit is often discarded!)

json-ld is so far down the list of pain points, and the pain comes from ignoring it or misusing it.

@evan well, that's the problem, again -- you see it as "your" thread, and i can't reply without copy-pasting a link to your post and appending "re:"? then appending "cc: evan"? so i can reply but i can't reply using inReplyTo? and you control all 400 posts downstream of your poll, *including the ones that don't mention you*? it's hard to make sense of that...

@evan this only works if you (and everyone else!) think "the root object" is special (and in effect treat it as the context). but others can and will disagree and diverge. if i reply to a cnn article and maintain my own comments section, cnn has no say in that. socially, in the case of private things, it's like "if you know you know" -- refer to a thing by id but only some people have further information about what it meant (at some point in time, etc)

@evan true, but this is where the problem arises...

@evan "the thread should have its own audience" is the main bit i am advocating for here i guess, as opposed to "every individual post has its own audience". with the latter you always get issues like this. with the former you bind context and audience together.