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

@cwebber @bkuhn @ossguy @richardfontana how do you launder proprietary codebases if the source isn't available? i just see this as 2 negatives since it would incentivize trade secrets

@evan tldr i don't think it's healthy to look at these discussions through the lens that people are "intentionally misinterpreting the specs in order to derive ridiculous conclusions", merely "fun thought experiments" intended so that "we can't have a conversation about the actual game", "fight[ing] tooth and nail to keep those loopholes from being closed". that reading is tantamount to bad faith, whereas a good faith reading is that people interpret the spec as best they can in their framework.

@evan for me, "the actual game" is maximizing people's expressiveness and letting them describe their lives one activity at a time. the goalpost is high fidelity and low miscommunication. a different goalpost might aim to lower fidelity just to get something to show up. if any conclusion seems ridiculous, then it's either not as ridiculous as it seems within a different framework, or there's something else that could be done to make it internally consistent. it's driven by use cases.

@evan i plead character limit and getting distracted by other things i'm doing rn, but i was using that as an example of a question that might *look* like an "intentional misinterpretation" but actually isn't. if you wanna publish activities then it's good faith to have discussions within the framework of publishing activities. but it could look like you're not playing "the actual game" by someone else's interpretation within a different framework.

@evan but what specifically incited my comment was the bit about people's intentions. i again can't speak for anyone else's intentions, but whenever i get involved in any conversation, i'm doing it to work toward some kind of practical answer. i'd like to assume others are doing the same, and that people aren't generally participating in bad faith or simply to have conversations with no conclusion.

@evan it wasn't intended as open question nor dog basketball. my point was we can either accommodate diverse viewpoints on what the "actual game" is and assume people are playing in good faith (and let them keep playing), or we close the door to those interpretations and uphold one of them as the correct interpretation (which might mean someone takes their ball and goes home). personally i'm team activity, but i'm not going to close the door on team note. i can't assume anyone else's position!

@evan sorry, i have no idea how to interpret this response in context of what came before it. what am i being thanked for? i was expressing confusion at the original premise.

@evan maybe some examples would clarify what you mean, but i'm not sure how to define "the actual game" in a way that everyone would agree they're playing it. like, what counts as a "loophole" and what counts as a fundamental use case? what makes a conclusion "ridiculous", or an interpretation "intentionally misinterpret[ed]"? these questions all depend on the frame of reference of whoever's asking them. i generally assume good faith whenever these things are being discussed. should we not?

@evan one example that illustrates just how much contention there is about even supposedly basic things: are activities content? one might argue they are the primary reason the specs exist at all, to publish activities to activity streams. someone else might equally argue that they are simply vehicles for distributed CRUD of notes, which are the real content. the specs currently support both interpretations. should one be closed as a loophole? is one an intentional misinterpretation? which one?

hex editor but for witches

@cwebber @ammaratef45 @passngrin technically you can add the structure back with json-ld framing, so it's not exactly "lost", just flattened.

re: linked lists i don't think it's any different than what happens in a programming language, is it? the underlying data structure can be expressed with a more efficient serialization (like how a python list *looks* like a c array but isn't) but it's still the same data. if the order matters then you have to store the order somehow, right?

@cwebber joke's on her, i subscribed for posts like this one and the good posts are just a bonus

@evan i would add that there are several other more actively maintained options, at least: https://json-ld.org/#developers

in the most basic case, expanding the document should make it unambiguous:

- all keys are normalized to full identifiers with exactly 1 possible representation instead of infinitely many
- all values are normalized to JSON
arrays of JSON objects
- those JSON objects explicitly say whether they have an id (Reference) or a value (Literal)

@jalcine everything is a notification by default so it's really more like a way to extract a "home feed" that is a subset of received notifications

but more importantly we are missing a way to login and a way to know what will be done to our submitted activities

@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.