#social 2018-08-07
2018-08-07 UTC
vasilakisfil_, vasilakisfil and xmpp-social joined the channel
# 
fr33domlover I like the idea of stoing activities raw if they're unknown. You can always convert them to other representations later if your server learns new activity types
# up201705417 fr33domlover: +1
KjetilK, kaniini, timbl, aaronpk, dlongley and tantek joined the channel
# kaniini puckipedia for what it's worth, i am open to implementing JSON-LD/LDS in pleroma in a limited way (no network requirement to validate the graph), but, only in transit, and ephemeral signatures are required for me to even consider it
# puckipedia kaniini: right. "no network requirement" is going to be Fun. officially speaking you need to parse possibly-remote contexts to expand a json-ld structure. And yeah, I see one reason for non-ephemeral signatures right now
# puckipedia but we're not at that point yet
# puckipedia (tbh I don't even like ld signatures myself? there's a lot of ambiguities that need to be fixed imo)
# puckipedia and yeah, Mastodon's sigs are ephemeral
# puckipedia .. btw there's some bug in federation between Kroeg and Pleroma and it might be my side but I'm not 100% sure what it could be
# kaniini somebody mentioned something about emojis
# kaniini puckipedia so how do i sign a JSON-LD structure without expanding it
# puckipedia you can't.
# kaniini :D
# kaniini therein lies one of the reasons why i don't like LDS
# puckipedia look I share your pain I implemented +-most of the JSON-LD api in rust manually
# kaniini i would prefer to implement JWS instead
# puckipedia welcome to the world of normalization hell
# puckipedia honestly yeah, we're stuck in normalization hell anyways
# kaniini Gargron can we just drop this LDS bullshit and implement JWS
# puckipedia it was
# kaniini Gargron i will literally give you money
# puckipedia gargron found it to be too complicated iirc
# kaniini but
# kaniini it's simpler
# puckipedia well, at least a JWK mechanism was considered
# kaniini than JSON LD
# kaniini RU*(&*($@$&*(@$^&*($^&*@^&*($&*($
# puckipedia kaniini: it's not if there's already a json-ld library in your preferred language
# kaniini puckipedia there is not one in elixir that is usable anyway
# puckipedia indeed
# puckipedia same for Rust
# puckipedia and the spec... the spec assumes you are writing an implementation in javascript
# kaniini there is a json ld library for elixir but it does not do expansion of remote contexts
# puckipedia tbh that's Mostly Fine, I think Mastodon does that too
# puckipedia idk how the async story is in elixir
# kaniini the async story is wonderful but that's not the point
# kaniini i don't want to trust data i don't control
# kaniini this is like, security 101
# saranix JWS is only simpler if you are using a library, from the spec, it is equally (infinitely) convoluted, just like json-ld
# saranix err lds I mean
# kaniini anyway, JWS seemed easy enough to me
# kaniini puckipedia so your implementation does not fetch remote contexts ?
# kaniini i do not even want to fetch them :)
# saranix I honestly don't even understand why canonicalization is such a hard requirement. Signing binary blobs is so much simpler, and for all of our purposes, all of them (that I can think of), that is Good Enough(TM)
# kaniini saranix that's http signatures and i do that already
# puckipedia saranix: *mumbles about ssb*
# saranix yeah but even for embedded attached objects... that's why everyone is using LDS, but it would be so much simpler to blob it, like salmon did
# kaniini saranix that doesn't prove that the original author created the object tho
# puckipedia kaniini: anyways. the only reason for LD signatures, imo, is t wo things:
# saranix kaniini: why not?
# puckipedia possible decentralization/nomadic IDs, and the relaying
# puckipedia the former, yeah, we're stuck with something signature-y
# kaniini pleroma does relaying by using announces
# puckipedia but for relaying? just create a second http signature signing just the digest? :P
# kaniini huh
# puckipedia idk that's my random idea
# kaniini that could work tho
# puckipedia I'm honestly wondering about creating decentralized identity support in activitypub
# puckipedia well, primarily nomadic i guess?
# puckipedia I'd probably just do did:apub:[public key hash or so]:/whatever/id/path/you/want -- and the server then maps public key to last known server or something
# puckipedia which is, yes, probably 90% what hubzilla does
# puckipedia but Yes It's A Good Thing and also it wouldn't be too hard to add support for this into e.g. Mastodon, as it's basically just mapping. biggest issue is going to be the export/import of data
# saranix
{"type":"Foo","attributedTo":"whoever","object":"{\"type\":\"Embedded\",\"content\":\"baz\",\"attributedTo\":\"thirdparty\"}","obj_signature":"thirdparty-sig"}# saranix json as a string inside json...lol
# puckipedia no way
# puckipedia a bunch of the stuff we're stuck with in ActivityPub is i feel primarily because Mastodon already had quite a following
# saranix it may not be 'pretty', but it's highly functional, and WAY easier to implement than LDS, which provides really no extra benefits, just more work
# puckipedia tbh, wait
# puckipedia isn't this just the whole http signature + digest header again?
# saranix no
# saranix different key
# saranix key1: header, key2: inside object
# 
tantek HTML comments to nest other markup: e.g. Trackback RDF/XML back in the day, or new WordPress Gutenberg putting pseudo-JSON in HTML comments e.g. https://github.com/WordPress/gutenberg/issues/5967
# kaniini This document was published by the RDF Working Group as a Recommendation.
# kaniini no wonder i hate this shit
# kaniini i wonder if W3C realizes that the vendors hate most of the garbage specs they produce
# kaniini i just want to point out
# kaniini that the formal specs for the json-ld algorithms are NON NORMATIVE
# kaniini can we PLEASE purge this TRASH from activitypub
# 
aaronpk whoa check out the "security considerations" section https://json-ld.org/spec/latest/json-ld/#iana-considerations
# puckipedia eh, cache it in memory for like a few months
# puckipedia also
# puckipedia don't serve it by third parties
# saranix yeah it's just a consideration, not an inevitability.
# saranix theory has an official definition, consideration does not
# kaniini JSON-LD needs to be removed from activitypub, period
# kaniini if it isn't removed by the end of august, i am going to just fork the protocol
# kaniini why be angry about a protocol when you can just fork it and fix it
# puckipedia mumbles xkcd
# kaniini don't care
# kaniini activitypub will die if vendors refuse to implement it any further
# kaniini remove JSON-LD now
# saranix not even. it's a federation standard, only way to federate is to use the same standard, forks and all :-P
# kaniini pleroma is a vendor, mastodon is a vendor, kroeg is a vendor
# kaniini we do not have to implement this garbage spec
# kaniini we can fork it and fix it
# kaniini i strongly suggest we do so
# tantek "security considerations" does have a definition in the context of standards, see https://www.ietf.org/rfc/rfc3552.txt and https://www.w3.org/TR/security-privacy-questionnaire/ and
# kaniini there is literally no reason to use the W3C to incubate the spec either
# puckipedia shrug, JSON-LD is totally fine imo. fixes a bunch of ambiguities that JSON has
# saranix I don't see any dealbreakers with json-ld. you're free to treat it like json and the basic will always work
# kaniini puckipedia network access is a dealbreaker
# kaniini saranix EXCEPT YOU CAN'T
# kaniini because of LDS
# puckipedia honestly I wouldn't do LDS
# saranix LDS is optional, and definitely a dealbreaker, LDS != JSON-LD
# kaniini and MASTODON has adopted LDS, which FORCES everyone else to
# puckipedia kaniini: nope
# kaniini puckipedia it does if you want to interop
# puckipedia nope
# kaniini yes
# kaniini mastodon and pleroma right now cannot agree on relay protocol
# kaniini garg wants LDS
# kaniini pleroma wants dereferenced IRIs
# kaniini this is a real interop problem
# kaniini a problem enabled by the absolute vagueness of the activitypub specification in the first place, incidentally
# puckipedia good news: you can just not implement relays and interoperate fine
# saranix yeah
# kaniini that's bad news
# kaniini consider that we want to implement relays for a reason
# puckipedia well then
# puckipedia fork the relay spec
# kaniini there is no fucking relay spec
# puckipedia make one
# kaniini there is no activitypub "spec" at all
# kaniini it is the same underspecified garbage as ostatus
# kaniini just json-ld instead of xml
# tantek kaniini could you file issues on ActivityPub for the specific places you find vagueness? https://github.com/w3c/activitypub/issues
# saranix lol. you want to see a protocol with no spec, check out matrix.org :-P
# puckipedia tantek: I think the issue is primarily with the implemented (sub/super)set of AP, that's undefined basically
# puckipedia tantek: I would suggest http signatures + the publicKey parts
# saranix yeah.. keyId and publicKeyPem
# saranix lol
# saranix things like fragments...was there ever a resolution on that? is it documented?
# puckipedia saranix: fragment identifiers, in practice, you just get the document without fragment and see if it's in there
# kaniini cwebber2 sure, i am willing to discuss, but my requirements at this point is that JSON-LD is dropped
# puckipedia do note. if we were to replace json-ld with something else, the resulting spec has to be pretty water tight
# kaniini keep in mind i have a file titled activitybomb.jsonld i will just start federating
# puckipedia I'm assuming it's an @context bomb
# kaniini dunno, but mastodon went to 100% CPU for 3 hours when encountering it
# kaniini so :)
# puckipedia right
# puckipedia yeah
# kaniini it is just a recursion bomb
# puckipedia kaniini: what if I found a bug that hits pleroma bad and use it to DoS your instance?
# kaniini puckipedia i'm down
# kaniini lets do it
# kaniini yeah?
# kaniini another form of collaboration could be to make a spec that is actually good
# saranix that's just rude
# kaniini i already disclosed the problem
# kaniini "it is just a recursion bomb"
# kaniini i'm sure they have
# kaniini i mean, i'm not really into this cowboy diplomacy shit
# kaniini i would rather just produce a spec that is actually good
# kaniini but the bottom line is, the W3C will not accept the spec i produce
# kaniini because
# kaniini - it will drop JSON-LD unapologetically
# kaniini - it will drop LDS unapologetically
# puckipedia do it!
# kaniini it is mentioned in authentication section
# kaniini and that is what leads to my current headache with this 'framework of specs'
# puckipedia kaniini: as is JWK iirc
# kaniini no
# saranix any spec that is superior *will* be implemented... there's tons of projects out there
# kaniini haha, you guys are hilarious
# kaniini the problem in this space is
# kaniini you need a userbase to bootstrap from
# kaniini mastodon's adoption of activitypub is what made people care
# kaniini that is just reality
# puckipedia ^
# kaniini yes, it can be improved
# kaniini by explicitly saying JSON-LD is only for validation
# kaniini and explicitly saying not to use security frameworks which require JSON-LD
# saranix decentralization has it's own sort of immunity to that. Sure there is a minimum viable population, but for example the hubzilla community was 300-500 people for years, now hubzilla speaks activitypub and suddenly it gains Mastodon's 500k instantly
# kaniini and explicitly saying that JSON-LD being used in a way that is required for fundamental operation is non-conformant
# kaniini in other words, LDS inline signatures should not be allowed
# puckipedia relays are not fundamental
# kaniini puckipedia no
# kaniini puckipedia they are not
# kaniini puckipedia but there is another reason for LDS: boosts
# kaniini puckipedia the IRI-dereferencing method does have scalability problems
# puckipedia except noone actually uses LDS for those yet
# saranix kaniini: explain the scalability problem
# kaniini puckipedia mastodon does
# kaniini puckipedia or, more specifically, mastodon plans to
# puckipedia unless things changed in the last +- few months they don't
# puckipedia ah
# kaniini puckipedia and does so already with relay
# puckipedia ... oh that'll be fucking fun, for boosts
# kaniini yes
# kaniini so
# kaniini i would like to work towards purging LDS from this protocol
# puckipedia it's probably going to be after [redacted bug] is fixed, else it'd be really fun
# kaniini it is unacceptable, ok
# kaniini that a protocol promises you can treat it like JSON
# kaniini and yet in the real world, very soon, it is possible that you will have to use LDS for specific activities to be accepted by the mainstream implementations
# kaniini so
# puckipedia if Gargron requires that boosts contain the boosted object with LDS
# puckipedia that will break fucking everything ever made
# kaniini this means, because of the fact that mastodon does this, i have to waste a LOT OF TIME
# kaniini implementing JSON LD
# kaniini so i can implement JSON LDS
# kaniini so
# saranix they wouldn't be compliant if they required something that isn't in the spec as a MUST
# kaniini cwebber2 yes i do
# kaniini the elixir JSON-LD implementation ok
# kaniini it does not support remote contexts
# saranix still wondering what the "sacalability problems" are
# kaniini and the author of it has explicitly said JSON-LD is trash and he does not care about it anymore
# kaniini i mean, i am just saying how it is
# puckipedia saranix: actor with large followerbase boosts your toot, and your instance will be hit with a few hundred/thousand requests
# kaniini because mastodon intends to use LDS requirement for boosts
# kaniini JSON LD, and LDS, are now practical requirements of every implementation
# kaniini because the big elephant in the room says so
# kaniini so
# kaniini what i would like to see
# kaniini in concrete terms
# saranix puckipedia: 50,000 * 1kb json object == 50 megabytes, my server can push that in under a second?
# kaniini is a well-specified way of handling inline signatures
# kaniini of sub objects
# puckipedia kaniini: note, LD sigantures will not be required for boosts, and if they will, most people here will vote against
# kaniini puckipedia it doesn't matter
# puckipedia it does
# kaniini if gargron moves forward on this
# puckipedia it definitely does
# kaniini by default
# kaniini you have to do it anyway
# puckipedia if Gargron adds this, and requires it
# puckipedia then it would break federation with all older instances
# kaniini it doesn't matter if he is conformant or not
# kaniini puckipedia
# kaniini he implemented contentMap and broke federation with older instances
# kaniini do you think he really cares
# puckipedia did contentMap break federation
# kaniini yes, with <2.0 instances
# saranix so.... it sounds like there isn't really a scalability problem, unless you code your impl poorly ;-) not a fault of the spec...
# kaniini he can do a similar flag day for LDS.
# puckipedia first time I have heard, and there's no issues on github
# kaniini puckipedia very few people run 1.6 anymore and he reverted it for now
# kaniini but still
# kaniini the reality is
# kaniini where he intends to go is LDS for boosts
# puckipedia that sounds more like an oversight imo
# kaniini he has said so many times
# kaniini and he keeps trying to sell me on this
# kaniini so, what i am telling you all is
# kaniini this will become the reality
# kaniini what is necessary is an alternative inline signature scheme
# kaniini which does not require JSON LD
# kaniini if there is not consensus on that
# puckipedia tbh I'm siding with saranix here, why even embed the objects
# stephank I haven't touch relay, or plenty of other use cases, but why wouldn't HTTP signatures work for everything?
# kaniini puckipedia i agree with saranix
# kaniini pleroma does not send objects, we ALWAYS IRI-dereference
# kaniini but mastodon is written in rails
# kaniini and so scalability concerns are understandable
# puckipedia I mean. Gargron even told *me* to put a cache in front of nginx
# puckipedia or well, between proxy_pass and nginx
# kaniini cwebber2 so
# puckipedia cache the activitypub objects and like. no problem
# kaniini you asked what is needed here
# kaniini what is needed is for activitypub 1.1
# kaniini to actually specify http signatures usage
# kaniini and to actually specify a way to validate objects
# kaniini WITHOUT using JSON LD
# kaniini alternatively
# kaniini ActivityStreams
# kaniini needs to have a frozen context
# kaniini so that we can just supply it in code
# saranix meh. The spec being silent on the matter means that if you want to trust the TLS cert of the server and don't care about replay and other attacks then you are more than welcome to
# kaniini saranix HTTP signature is needed for *push*
# saranix noooooot reallyyy
# puckipedia saranix: eh, http signatures are needed for now for that. it's mostly to avoid a situation where user A gets a private message from user B, then posts it into the inbox of user C
# puckipedia also yes you could sign a header-less http signature
# kaniini ^^^^^^^^^^^
# puckipedia butehm. ew
# saranix yeah but you can *always* dereference
# kaniini so
# saranix like literally everything
# kaniini here's the bottom line
# kaniini what i'm looking for is this
# kaniini - always dereference by IRI
# saranix the push can be just a simple notification, no object sent
# kaniini (this will not be accepted by gargron)
# kaniini if "always dereference by IRI" is not acceptable
# saranix the spec requires that you allow that mode
# kaniini then we need an inline signature scheme
# puckipedia actually wow relay functionality in kroeg is like three lines of code
# stephank I like no context. Or at least, implementations should be able to ignore it. So compacting to `as:xyz` or `https://xyz` should be illegal IMHO. And specify what is embedded and what isn't. (With the least amount of ORs.)
# saranix so not allowing it means you are not spec compliant
# saranix and your solution is to change the spec to get around 1 impl not being spec compliant
# kaniini but what i am telling you is
# kaniini mastodon itself
# kaniini will become noncompliant
# kaniini cwebber2 JSON Schema
# puckipedia ew
# stephank cwebber2: Some stuff like Public appears to compact to as:Public. :/
# kaniini yes, it is
# puckipedia stephank: that should be fixed in the as2 context imo
# kaniini cwebber2 yes, and the real world does not care about semantics
# puckipedia cwebber2: who was responsible for the as2 context again?
# kaniini anyway
# kaniini there's 3 outcomes, any of which would solve this problem
# puckipedia cwebber2: I would probably suggest the Public term be removed and replaced by "as:Public": null to avoid semantic issues
# puckipedia i'm unsure why the Public term is there imo?
# kaniini 1. Always require dereferencing by IRI of objects. No subobjects ever allowed.
# puckipedia cwebber2: right, will propose next time
# kaniini 2. Freeze the contents of the activitystreams context so that it can be hardcoded. Versioning can be used for future additions.
# kaniini (this would allow me to be okay with implementing JSON LD in Pleroma)
# saranix kaniini: that isn't necessary, subobjects MUST have an id field with a dereferencable id, so you can ignore the rest of the object
# kaniini saranix i understand that, and pleroma already does this
# puckipedia kaniini: there's already hash-based histories of activitystreams contexts
# puckipedia kaniini: https://www.w3.org/ns/activitystreams-history/
# puckipedia however ehm. using these breaks Mastodon compat right now
# puckipedia will open issue for that
# kaniini puckipedia that doesn't do me any good, because i do not wish to handle remote contexts
# kaniini my solution for remote contexts would be to send them to the trash bin
# puckipedia the thing is, they are hashed so you can hard-code them :P
# kaniini doesn't help with inbound messages
# puckipedia assume the as2 context is the latest hashed one
# kaniini 3. Implement some sort of inline signature validation thing
# kaniini cwebber2 because i want to have a rigidly defined answer for everything in @context. i want to say if somebody sends me a message containing a @context that i do not know, that i can just discard it
# kaniini so, clearly i cannot discard https://www.w3.org/ns/activitystreams
# kaniini ^^^^^^^^^^^^^^^
# stephank That does sound nice.
# kaniini this is security 101
# kaniini it is not acceptable to remote fetch https://www.w3.org/ns/activitystreams
# kaniini even with caching
# kaniini how long should we cache? forever?
# kaniini no, it needs to be properly versioned and supplied in a format that can just be embedded into the implementation
# puckipedia so, the puzzle here is
# puckipedia should extensions send their @context to every single server every single time they post a thing
# stephank Is an option 4. maybe to have JSON-LD as an addon? So the spec defines a fixed JSON format for everything, and then specifies how that relates to JSON-LD for those who want to use tooling.
# kaniini stephank yes
# kaniini that is something else i would like to see
# puckipedia there's a few painful points if you were to try that
# kaniini removal of JSON-LD from the master spec, and if you want to use it, there can be a separate spec that describes how JSON-LD applies here
# kaniini puckipedia the bottom line is
# kaniini puckipedia i don't care about extensions
# kaniini cwebber2 solve what problems
# kaniini here is what you do
# kaniini you take https://www.w3.org/ns/activitystreams and you release it as a file, with a version
# puckipedia kaniini: you don't care about indicating an account as private or public, or a post being sensitive? or custom emoji, or hashtags?
# kaniini ActivityStreams 2.0.0
# saranix but..... does it really matter (versioning)? Let's say your software hardcodes the fields from the AS context that you use, now suddenly it receives a message using a newer version of the context containing fields that you don't understand. Fetching a new context won't help you understand them. You're program still won't have code to deal with them magically, so the only thing you *can* do is ignore them.
# kaniini puckipedia none of those are in the JSON-LD @context we send now
# puckipedia aaronpk: so Here's The Thing
# kaniini aaronpk a great observation. what if somebody deletes that document someday
# puckipedia aaronpk: I'd host the contents of the AS2 context in the kroeg server
# puckipedia if it didn't, context for e.g. puckipedia.com/.json would just be "@context": "https://puckipedia.com/-/context"
# kaniini anyway
# puckipedia would one single, non recursive, context be OK?
# kaniini puckipedia i would reject those messages on principle
# puckipedia hosted on the same server as the source of the object
# kaniini but i fundamentally hate JSON LD
# kaniini and, would prefer to see it removed from the spec altogether. you can have a spec for JSON-LD matters separate from the main spec.
# kaniini of course, none of this matters
# puckipedia aaronpk: well, you would limit it to one
# kaniini because i have to implement this stupidity anyway
# kaniini something which is very frustrating to me
# kaniini by the way
# kaniini what does mastodon do if i send
# kaniini "@context": "https://www.fbi.gov/"
# kaniini and
# kaniini what happens if John Q. Scriptkiddie
# kaniini starts spamming mastodon servers with that
# kaniini like i am fundamentally opposed to this stuff for a lot of reasons
# kaniini the network access is really problematic
# puckipedia kaniini: that's why I'm suggesting same-origin
# kaniini puckipedia and pushes?
# puckipedia context on the same host as the origin of the push
# kaniini cwebber2 yes, it is a problem there too
# kaniini but it's different
# saranix fetch -> www.fbi.gov with Accept:activitypub -> servers Content-type: text/html -> ignore. I see no problem
# kaniini anyway
# kaniini i'm really not convinced
# kaniini that activitypub will get better
# kaniini saranix
# kaniini it doesn't matter
# kaniini about the accept
# saranix aaronpk: LOL
# kaniini because you're still burning CPU time
# kaniini and bandwidth of fbi.gov server
# kaniini cwebber2 and i don't like the IRI dereferencing, but it's the only way to guarantee that an origin maintains control over it's objects
# saranix kaniini: and you're wasting cpu time and bandwidth accepting an email about penis pills.... so what?
# kaniini saranix the difference is
# kaniini saranix fbi.gov may care
# kaniini saranix and go to www.innocentactivitypubinstance.com's owner's house
# kaniini saranix and do what fbi people do when they go to your house
# saranix csarven: LOL
# kaniini cwebber2 the difference is
# puckipedia kaniini: I don't think FBI goes to like, Google's offices because they load all the pages
# kaniini cwebber2 i'm willing to trust that an origin is okay with providing its objects
# kaniini cwebber2 i don't want to have to trust www.w3.org/ns/activitystreams to continue existing
# stephank If we strip the spec of JSON-LD, we can still require @context, and use it as an identifier. Then implementations can choose to use JSON-LD or plain JSON, checking @context before validating the contents. There'd be no need for dereferencing.
# saranix also, to protect yourself from *many* attack vectors, your incoming process should not be the same process to fetch IRIs. They should be queued and handled seperately. That's just security 101.
# kaniini stephank yes, this is the root of my 'litepub' proposal
# puckipedia congrats now you're still splintering the network
# stephank And I think it'd be wise to have rules for dereferencing anything else the spec requires (actors, objects, public keys, etc.), such as same-origin.
# puckipedia stephank: I see use in objects being non-same-origin
# saranix finds it odd that people scared that optional things in the spec might be bad somehow, are advocating "solutions" of *requiring* things in the spec that would massively break everything without even solving the optional thing that wasn't really a problem in the first place
# stephank puckipedia: Any idea what for? That's curious :)
# puckipedia i mean yes, that's the obvious one, but imagine e.g. a version of the chess thing
# puckipedia but instead, you log into the site, and it uses ap c2s to talk to your home server
# puckipedia however, you don't trust it with arbitrary messages, so you say "any Create must be hosted on hxxp://chess.example"
# kaniini anyway
# kaniini saranix what i propose actually does not break realworld compatibility at all
# kaniini in fact, it is informed by implementing activitypub in the real world
# saranix puckipedia: I still say that there should be a facility so the home server can (after providing a UI to the customer to approve it) sign any arbitrary objects so that indeed homeserver.example signs all activity's owned by homeserver.example actor
# kaniini but
# kaniini this still doesn't solve problems
# puckipedia saranix: yeah, that too probably
# kaniini my goal isn't related to activitypub per se
# kaniini but to mastodon compatibility
# kaniini my frustration with activitypub is the underspecification has allowed mastodon to get away with murder
# saranix I'm a big fan of 100% document self-origination (i.e. if I made it, my machine has a copy first)
# kaniini and, in practice, to be fully compatible with mastodon
# kaniini you MUST implement JSON-LD
# puckipedia kaniini: the thing is, well, we can't write a spec without real world experience, and we can't get real world experience with a spec
# kaniini you MUST implement LDS
# kaniini so, the real world experience points at JSON-LD and LDS being hard requirements of activitypub
# kaniini this was enabled by the spec encouraging use of both
# kaniini so you can say "yeah activitypub can be done with pure JSON" all you want
# kaniini but if you want to play with the big elephant, you're playing by their rules
# kaniini so if there is real commitment to "you can do activitypub with pure JSON"
# saranix you act like mastodon's actions are set in stone and irreversible
# kaniini saranix i do not
# kaniini saranix that is in fact, why i am requesting spec guidance
# kaniini if i say hey lets come to consensus on how to solve the relay problem as part of activitypub 1.1
# kaniini he will do it
# saranix you are not requesting guidance, our guidance has been, ignore the non-compliant stuff and you will still be compatible with all of our implementations which are compliant. end of story.
# puckipedia ^
# puckipedia or well, first part definitely
# kaniini your guidance doesn't solve the relay problem
# kaniini and it does not solve the problem that mastodon 3.x will likely require LDS boosts
# puckipedia I like your "likely require"
# saranix again, I say, if the problem is mastodon isn't spec compliant, then in no way can changing the spec solv the problem.
# kaniini i say likely because i'm not gargron, i can only read the tea leaves and make conclusions
# puckipedia kaniini: i'm aiming mostly at the "require"
# kaniini i can also say that the implied requirement of JSON-LD
# kaniini and LDS
# kaniini (because of mastodon)
# kaniini is one of the main reasons why implementations are stalling
# kaniini on federation
# puckipedia i have seen no issue with LDS
# kaniini there's a lot of implementations which would like to develop against my description of activitypub
# puckipedia please note: I use no LD signatures, and Mastodon compat is fine
# puckipedia Pleroma compat, however...
# kaniini pleroma sees activitypub as pure json
# saranix yeah wasn't there some problem with pleroma using a different PEM format than everyone else?
# kaniini which is probably more evidence that the claim that "JSON-LD is not a hard requirement" is not really workable
# puckipedia they were both PEM keys, so I would say that's not pleroma's fault
# kaniini the encoding we presented is the old one actually
# kaniini i switched it to the new one
# kaniini anyway
# kaniini puckipedia i am going to be blunt, i really don't give a damn if the messages pleroma send validate as JSON-LD
# kaniini the spec says i can treat it as JSON
# kaniini so i treat it as JSON
# puckipedia that'd be impressive, since basically any json you can build is valid json-ld
# kaniini i would like to continue treating it as JSON
# kaniini puckipedia ok
# puckipedia if it parses like you think it will, that's another question
# kaniini puckipedia if the resulting RDF graph
# kaniini puckipedia is not conformant
# kaniini puckipedia i really don't care
# kaniini i really like Zot6 as a protocol
# kaniini mostly because it does not use JSON-LD
# kaniini i have considered switching pleroma to use that as default wire protocol in fact
# saranix kaniini: I can't wait til zot6 gets published! >o<
# puckipedia aaronpk: can't do lists of lists
# kaniini haha, the miracle protocol can't do things JSON can do
# kaniini amazing
# puckipedia and yeah, I think 1.1 fixed that possibly
# kaniini notes to self to use lists-of-lists in future pleroma messages
# puckipedia kaniini: you'd be going quite out of your way
# kaniini civil disobedience
# saranix remembers the first time I used 6-times-dereferenced pointers in C for a perfectly valid use case (though I can't remember what that was)
# kaniini ah, a six star programmer
# kaniini anyway
# kaniini puckipedia outside of mastodon compat why should i care at all about json ld
# kaniini i've given json ld many chances
# saranix I haven't given it any, and have no plans to. I don't see the problem. In my experience, treating it just like json works just fine
# kaniini saranix the problem is signing with LDS
# puckipedia kaniini: disambiguations and extensions
# saranix idc about LDS either
# kaniini i care about mastodon compat
# kaniini which means i have to care about LDS
# saranix and as puckipedia said, kroeg works without lds with mastodon
# kaniini it works partially
# kaniini kroeg cannot make use of a mastodon relay
# saranix what is a mastodon relay?
# kaniini it relays messages
# kaniini obviously
# puckipedia saranix: the relay gets sent public activities, and it relays those to all 'followers'
# saranix but you don't have to use it?
# kaniini no
# kaniini it is not
# saranix I can just use sharedInbox, right?
# kaniini okay i give up
# puckipedia saranix: different usecase
# kaniini i just give up
# puckipedia saranix: the idea of the relay is that you can prime your federated timeline
# kaniini i'm going to go see if i can't just read kroeg's sources
# kaniini and figure out JSON LD from that
# puckipedia https://github.com/kroeg/jsonld-rs
# kaniini maybe it will be more enlightening
# kaniini than trying to read this W3C spec
# puckipedia I'm slowly processing the json-ld spec into something usable tbh
# saranix puckipedia: when you say prime timeline I picture fetching outboxes...????
# puckipedia saranix: basically, a new instance has zero posts it knows, so it's difficult to find new content
# puckipedia the relay fixes that by feeding public messages into your instance, so you don't pull
cwebber2 joined the channel
# kaniini the problem is
# kaniini JSON-LD could have been an ok spec
# kaniini but then the RDF working group had to get involved
# kaniini presumably because if they didn't, they were all going to be unemployed
# saranix But I can still pull if I want to?
# puckipedia you can still read remote outboxes yes
# puckipedia but that's more work
# kaniini and now the spec is infected by RDF crazyness
# saranix to me LDS is more work
# saranix much more
# puckipedia kaniini: tbh shower me with rdf
# saranix I still don't see a problem.
# saranix screw the useless relays. who cares?
# kaniini saranix well
# kaniini pleroma does have relaying
# kaniini in a different way
# kaniini we just provide a stream of Announces
# kaniini with dereferenced IRIs
# kaniini it works pretty nicely
# saranix sounds nice
# puckipedia kaniini: tbh just force feed them into the sharedInbox of the mastodon server
# saranix I still see no problem.
# kaniini puckipedia can't. the relay requires LDS.
# saranix mastodon's poor coding overloads their crappy servers? meh. don't care. not my problem.
# puckipedia kaniini: no, not that
# kaniini csarven no
# kaniini csarven i am attributing that to general semantic web semantic webbiness
# kaniini i am trying to be nice
# kaniini if you want the uncensored version ...
# tantek saranix, re: who cares? some folks care, see https://indieweb.org/Bridgy_Fed for more on the fed.brid.gy relay to AP / Mastodon etc.
# puckipedia drown me in semantic web imo
# puckipedia linked data all the way, back to actually usable webpages
# saranix puckipedia: I happen to get aroused at the idea of semantic data and sparql and all that stuff
# kaniini csarven i'm aware
# kaniini JSON-LD was not originally an RDF syntax
# puckipedia i propose we replace json-ld with n-quads
# kaniini i mean
# kaniini if you want to know my real opinions on the semantic web
# kaniini i can share them
# kaniini but cwebber2 will be quite upset
# kaniini so i think
# kaniini i will not
# saranix well, to be fair, html and http are both pretty horrible :-P
# kaniini RDF, JSON-LD, SPARQL are horrible
# kaniini TURTLE is an insult to actual turtles
# kaniini i went to the zoo and asked. 0 out of 5 turtles interviewed approved of TURTLE
# kaniini TURTL?
# kaniini i mean, i just want to work with JSON ok
# kaniini horrible
# saranix you forgot GRDDL (is that the right number of Ds?)
# kaniini i mean, i guess i really just don't understand the use case for all of these things
# kaniini probably also don't care
# kaniini and the problem is
# kaniini those people with those things
# kaniini want to have a real world usecase
# kaniini voila: infecting activitypub with it
# kaniini csarven begrudgingly the HTML dom, manipulated by javascript
# kaniini who says i care
# kaniini about archivability
# kaniini accessibility, in terms of humans, is simple. you follow the ARIA guidelines, something that W3C actually produced that is good
# kaniini the wayback machine cannot preserve pleroma content. i consider this a feature.
# kaniini RDF is like
# kaniini fundamentally incompatible with my mental model for data
# kaniini if you have
# kaniini i mean
# kaniini for example
# kaniini
{"@context": "https://www.w3.org/blahblah", "foo": "bar"}# kaniini i get this
# kaniini i also get that expands to
# kaniini
{"https://www.w3.org/blahblah/foo": "bar"}# kaniini but then you get into this
# kaniini
{"@id": "_:b0", "@value": "bar"} shit# kaniini and i literally cannot
# kaniini i just can't
# kaniini oh great, i've activated a W3C sales droid here
# kaniini i was kidding
# kaniini anyway
# kaniini
{"@id": "_:b0"}# kaniini like what does it even mean
# kaniini obviously opening of a JSON object
# kaniini csarven i have to use that
# kaniini to represent the RDF graph
# kaniini for LDS signature
# kaniini it is an 'empty node'
# kaniini yes, for the same reason JSON-LD will ultimately fail
# kaniini and if activitypub evolves into something else not maintained at w3c? :)
# saranix I dunno abut all that, but to me, the idea that you can take a ton of standalone related XML objects, then transmogrify them with an XSLT into an RDF, then make a UI out of it by adding a CSS, making it pretty for both humans and machines, is nothing short of magical
# tuxether[m] XD
# tuxether[m] wasn't litepub exactly that?
# saranix never heard of it
_xmpp-social, kaniini and cwebber2 joined the channel
# kaniini activitypub without JSON-LD
# kaniini e.g. activitypub you can actually implement on a staticly compiled language
# kaniini and yes, elixir really isn't dynamic enough to handle JSON-LD in a usable way, which is presumably why the guy gave up on it
# puckipedia shrug, I don't think statically compiled languages can nicely do the flexibility of activitypub even if it were without json-ld
# puckipedia and honestly, the node maps are pretty easy to manipulate
# 
cwebber2 it's a general problem that if people want to convert incoming data in an open world system into statically typed records that you're going to run into a problem, because... it's an open world system. You can do it though by making records for the structures you expect, then leaving a slot open to dump all the properties you don't recognize. That way you can preserve the data without having to understand it
# puckipedia no, I mean, e.g. object can be either an "Object" or an ID, or possibly even a list of ID/Objects
# puckipedia or attributedTo, etc
# kaniini anyway
# kaniini tantek https://pleroma.site/notice/2300746
# kaniini tantek there's no actual spec yet, but strong interest in one. at this point i may actually do it, because i am really sick and tired of this JSON-LD thing.
# kaniini tantek i have no interest in 'consensus based protocol design' with people who want to keep JSON-LD
# kaniini in fact, if litepub fork happens, participation will be limited to people who have actually done the work to federate, and thus understand why JSON-LD is unacceptable
# kaniini tantek there is no room for JSON-LD in litepub, zero.
# kaniini a message without @context is a perfectly valid litepub message if you don't care about AP.
# kaniini in fact, a litepub spec would start by *deprecating* @context
# kaniini for "legacy compatibility with ActivityPub only"
# kaniini you can't. AP requires it.
# kaniini a message without @context is non-conformant
# kaniini mastodon will not accept activitypub messages without it
# puckipedia according to what text in the spec is it non-conformant?
# puckipedia for reference https://github.com/tootsuite/mastodon/issues/8139
# kaniini tantek that's cool, but litepub is sort of a "interoperate with the real world" type initiative
# kaniini so, in litepub that means it's required-but-deprecated
# kaniini i really can't, because all of the docs show @context being used too
# kaniini my requirements are too strict, sorry
# kaniini the real world does not want JSON-LD
# kaniini it is time for there to be a WHATWG type thing for activitypub that represents the real world
# kaniini consensus based development created the JSON-LD problem to begin with
# kaniini the Trusted Experts or whoever were invited to draft the initial spec clearly lacked real world experience engineering these things
# kaniini but it is fine, we will fix it, with litepub
# kaniini and JSON-LD will be phased out.
# 
bigbluehat not sure the scope of "real world" but JSON-LD is increasing in usage, not declining
# kaniini for some applications, sure.
# kaniini for S2S protocols, definitely not.
# bigbluehat if there are specific, testable concerns, it'd be great to have you raise them on https://github.com/w3c/json-ld-syntax/issues or https://github.com/w3c/json-ld-api/issues
# kaniini sure, how about not using just URIs and depth counter for cycle breaking
# kaniini how about having a spec that doesn't define the algorithm but then call it non-normative
# kaniini i mean, i get it, it's the W3C
# kaniini everything has to have the Semantic Web pixie dust
# kaniini it's cool, really.
# kaniini but the real world does not need the semantic web in it's S2S protocols
# kaniini tantek i guess what i am saying is
# kaniini i don't understand what a dialog could achieve
# kaniini cwebber2 has already stated that dropping JSON-LD is never going to happen
# kaniini in this very IRC channel
# tantek can you cite a https://chat.indieweb.org/social URL to where he said that?
# kaniini that is not an acceptable option to me
# kaniini thusly, forking is necessary
# kaniini so i question what is the point in even having a dialog
# kaniini if it is there, as an optional component, it will eventually become the mainstream, and thus infect the S2S protocol again
# kaniini this is not acceptable to me
# kaniini tantek it doesn't matter what aspects are in common
# kaniini yes, the entire point to litepub
# kaniini is that JSON-LD, RDF, Semantic Web, never happened
# kaniini it is intended to exist from that editorial perspective
# bigbluehat kaniini: it would be helpful--for dialog, etc--if you narrowed the scope of your complains beyond just "JSON-LD" (etc)
# bigbluehat specific bugs/issues/scenarios may be fixable or avoidable
# kaniini i really don't care to contribute to semantic web initiatives
# bigbluehat tnx tantek
# bigbluehat was there a link for that non-normative reference?
# kaniini i wrote many posts about hating JSON-LD for months
# bigbluehat because I'm pretty sure there's a spec in progress https://w3c.github.io/json-ld-api/
# bigbluehat (full disclosure, I'm a co-chair of that in-progres WG)
# kaniini ok
# kaniini well
# kaniini i am glad you like your spec
# kaniini i am sure it will someday be a good spec
# kaniini but i don't want it anywhere near the s2s protocol
# bigbluehat kaniini: fwiw, it's not "my" spec. I'm just a chair, not an editor
# bigbluehat but I would like to get links to your posts fwiw
# kaniini bigbluehat you really don't want to read them
# kaniini bigbluehat i assure you
# kaniini bigbluehat because, i basically have not written nice things about JSON-LD
# bigbluehat kaniini: if their constructive and collaboratively spirited, then I'd love to read them :)
# bigbluehat kaniini: if not, then yeah...I've got other things to do
# kaniini bigbluehat no, they are frustration-driven
# bigbluehat k. all good
# kaniini you can read whatever you want to read, what i want is an S2S protocol where JSON-LD is verboten
# kaniini you people do not want this
# bigbluehat kaniini: because? -- this is where the constructive bit would be helpful
# kaniini bigbluehat because i'm implementing high performance, high security server code and JSON-LD is the antithesis of that
# bigbluehat kaniini: not sure that's a provable assumption given that others are also building high performance, high security server code where JSON-LD is a requirement
# kaniini bigbluehat i am sure it is possible, but it is more work than simply not doing so
# kaniini bigbluehat first rule of security, don't do more than you have to
# bigbluehat if there are specific issues, there's a group that'd love to fix it--in fact...that's our charter
# kaniini i believe i mentioned improving cycle breaking robustness as a starting point
# kaniini another hard requirement for me to even consider this acceptable
# kaniini would be to make it possible to expand an RDF graph
# kaniini without network access
# kaniini no, i refuse to attach myself to semantic web specs
# bigbluehat kaniini: it's already possible to expand the graph without network access
# kaniini bigbluehat it is not if @context refers to a remote
# bigbluehat if you've gotten that "remote context" via some other channel and cached it, then you can expand it
# kaniini csarven i have stated it and will state it again: i do not want semantic web stuff in activitypub S2S
# kaniini bigbluehat which is fine, except guess what
# kaniini bigbluehat https://www.w3.org/ns/activitystreams
# kaniini bigbluehat is not formally versioned
# kaniini bigbluehat so i can't just say "this jsonld file is our opinion of https://www.w3.org/ns/activitystreams, it corresponds to the activitystreams 2.0 context version 20180707"
# puckipedia feel free to use any of https://www.w3.org/ns/activitystreams-history/ imo
# kaniini this is not even specified
# bigbluehat that scenario is partly where https://github.com/w3c/json-ld-syntax/issues/9 came from, fwiw
# kaniini in activitypub spec
# kaniini ok
# kaniini i mean, it is great talking about json-ld apologetics, but i have a fork to plan
# kaniini since W3C has no practical experience implementing secure S2S protocols (as seen by JSON-LD in activitypub S2S), so i will just fix it myself
# kaniini i'm not convinced
# kaniini then prove your independence and release activitypub 1.1 without JSON-LD
# kaniini meanwhile i will be forking
# kaniini to ensure it actually happens
# kaniini and yet, there is JSON-LD
# kaniini @context is required if you want to interop with the only implementation that actually matters
# kaniini that's a pretty strong endorsement of JSON-LD
# kaniini so, like i said, i want to see the protocol move in a direction that repeals and does not replace JSON-LD
# kaniini really, does your toy implementation have 1,000,000 users?
# kaniini aaronpk i wouldn't call it a fork so much as a specified profile of activitypub
# kaniini which does not have JSON-LD
# puckipedia aaronpk++
# kaniini and which makes JSON-LD explicitly verboten
# kaniini tantek well
# kaniini aaronpk sure, but JSON-LD must die
# kaniini i will work with the WG if JSON-LD will die
# kaniini otherwise i see no point
# kaniini as in, i am being very clear that i want JSON-LD removed from activitypub
# kaniini tantek i have some level of interop without JSON-LD
# kaniini aaronpk but there is no energy for that
# kaniini that's what litepub is about
# kaniini quite literally
# kaniini mastodon is on it's own
# kaniini when it comes to json-ld
# kaniini tantek it won't
# kaniini tantek we have interop today, without it. what i want to do is improve interop, by replacing the things mastodon uses JSON-LD for (LDS) with something else. and then having this be the standard.
# kaniini this is why i am opposed to JSON-LD.
# kaniini i do not want to exchange LDS for some other signing mechanism that uses JSON-LD.
# kaniini this is the point of litepub
# kaniini to fill in the details
# kaniini not just that
# kaniini all of it
# kaniini including webfinger
# kaniini because that's what all of us are using
# kaniini and litepub is meant to be about all of us, not all of you
# kaniini you all can enjoy the semantic web
# kaniini there are places, perhaps that collaboration is possible, but litepub is meant to be a spec where if you follow it, everything will just work
# kaniini including person@domain finding
# kaniini note that webfinger wouldn't be a hard requirement of litepub, but it will be mentioned
# kaniini tantek webfinger is necessary in the specific usecase litepub covers
# kaniini a pixelfed user will not wish to tag her friend as https://example.com/~alyssa
# kaniini they just want to type something like
# kaniini "@alyssa@example.com and i had a nice time in paris, check out this tower"
# kaniini and webfinger is what provides this for us
# kaniini so yes, it goes into litepub
# kaniini it is not, but that's how it is done in the current AP world
# kaniini i understand that the W3C is opposed to it, since it's not their baby
# kaniini but i am not the W3C
# kaniini there is explicit activitypub-wide position on it
# kaniini evanp wanted it, and you guys told him no
# kaniini see, everything about activitypub pisses me off
# kaniini you're right, it's not just JSON-LD
# kaniini if evanp who, by far, is *the* expert in this space
# kaniini cannot get what he wants
# kaniini who can
# kaniini i mean, i'm just saying
# kaniini activitypub spec even fails to mention webfinger as a possibility
# kaniini that seems pretty biased to me
# kaniini your point being what
# kaniini litepub is meant to provide concrete answers
# kaniini it is not a 'framework'
# kaniini tantek i presume bias from the fact that the github bug essentially told him to fuck off with it
kaniini joined the channel
# kaniini tantek i presume bias from the fact that the github bug essentially told him to fuck off with it. https://github.com/w3c/activitypub/issues/20
# kaniini so bluntly.
# kaniini the only way i would ever dream of collaborating with this group on that level
# kaniini is if a LOT of things changed
# kaniini everything i see shows me that the group is NOT equipped to do protocol engineering for the real world implementors
# kaniini i pray that Zot6 will come soon and end this madness
kaniini_ joined the channel
# kaniini_ it would be really great if my generator would continue to stay on
# kaniini_ anyway
# kaniini_ tantek i am not convinced that activitypub will evolve in a direction that is actually meant for real-world implementors
# kaniini_ Zot6 is the new hubzilla s2s protocol
# kaniini_ all i can really do is work to make activitypub sane from the outside
# kaniini_ the proposals the real world wants very clearly do not match what the activitypub spec wishes to provide
# kaniini_ hince, litepub
# kaniini_ why should i believe that i will be treated any differently than evanp or mike macgirvin
# kaniini_ i have no interest in RDF, so i doubt my opinions will be given consideration
# kaniini_ i mean, i'm just not convinced
# kaniini_ instead, ultimately, my suggestions will be turned into webshit
# kaniini_ at any rate, litepub will exist as a profile of activitypub that specifies the details activitypub doesn't due to political compromise.
# kaniini_ maybe there will be collaboration, maybe not
# kaniini_ but so far i am not convinced this is a good use of my time
# kaniini_ i propose we let things settle and see how the litepub group can interact with the socialcg
# kaniini_ but it is obvious, at least to me, that such group is necessary
# kaniini_ at any rate, to be clear, despite my frustrations with activitypub current state
# kaniini_ i prefer to see litepub become a useful contribution to the overall ecosystem