#social 2018-07-13
2018-07-13 UTC
fr33domlover, fr33domlover1, fr33domlover2, fr33domlover3 and fr33domlover4 joined the channel
# 
dansup Gargron: how mastodon uses redis has been a big inspiration for pixelfed, thanks a lot!
fr33domlover, fr33domlover1, fr33domlover2, fr33domlover3 and fr33domlover4 joined the channel
# dansup aaronpk: https://mastodon.social/@dansup/100365114885447693
# 
Loqi [dansup] @christianbundy @maloki I think MicroPub might be something to pursue! https://www.w3.org/TR/micropub/ #indieweb
fr33domlover1 joined the channel
# dansup I think MicroPub support could be interesting, as a proxy for C2S so you only need S2S
fr33domlover2, fr33domlover and fr33domlover1 joined the channel
xmpp-social, fr33domlover, vasilakisfil, timbl and timbl_ joined the channel
# 
aaronpk here's my post https://aaronparecki.com/2018/07/13/6/ and here's the post I was replying to https://octodon.social/@cwebber/100368138697354408 where I wanted @craigmaloney to see my reply too
timbl joined the channel
# nightpool[m] aaronpk: notifications work only off of @mentions
# nightpool[m] (as represented by Mentions in the tags array)
# nightpool[m] So if you want someone to be notified of your post, you have to @ mention them
# nightpool[m] sure.
# nightpool[m] you should add them to the to if you're directing it at them
# nightpool[m] to is for delivery, tags Mention is for "this is an @mention parsed from the post content"
# nightpool[m] mastodon ties them together because of it's microblogging text-first design
# nightpool[m] weirdly it looks like cybre.space and octodon saw different versions of the post?
# nightpool[m] uploaded an image: image.png (58KB) <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/sWnbITYbhpKilExRLFGzDxdC>
# nightpool[m] uploaded an image: image.png (53KB) <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/TPwTruAooYhgZGkNDdVTDQgb>
# nightpool[m] I loaded it via url
# nightpool[m] that's....... confusing
# nightpool[m] to be clear, they won't see a notification unless they're Mention'd in the tags array
# nightpool[m] It considers it a reply, just not one that's directed at them
# nightpool[m] One that mentions them
# nightpool[m] inReplyTo—shows up in the thread view
# nightpool[m] Mention—shows up in notifications
# nightpool[m] they're completely decoupled.
# nightpool[m] replies don't mean anything to mastodon as far as notifications go, because that's how twitter works.
# nightpool[m] they only show replies if you're mentioned in them.
# aaronpk there is no "@aaronpk" in this tweet text https://media.aaronpk.com/Screen-Shot-2018-07-13-09-24-53-0eayNIvN7B.jpg
# nightpool[m] oh, sure.
# nightpool[m] but mastodon is trying to be "old twitter" :P
# nightpool[m] (also i think there's still an @aaronpk on the backend, it just gets parsed out for display)
# nightpool[m] ¯_(ツ)_/¯
# nightpool[m] well, like I said, you really just have to include the mention
# nightpool[m] although it will be very surprising for mastodon users if they see something they're not tagged in in their notifications
# nightpool[m] i guess the real thing here is that you can't deliver two different copies of the same status to the same server
# nightpool[m] so craigmaloney didn't get tagged ig because you sent the cwebber one first, or something
# nightpool[m] yeah well in that case there's no way it would have notified him
# nightpool[m] just like if you had unchecked his box on twitter :P
# nightpool[m] yes
# nightpool[m] although again the only actual requirement is a Mention in the tags array
# nightpool[m] but it would be Surprising for him to see that without his name being in the text
# nightpool[m] also in re the actual content of that message:
# nightpool[m] what cwebber is saying does actually work
# nightpool[m] you just have to set your `id` to the jsonld representation
# nightpool[m] and then you can set your human-readable `url` property to the post permalink
# nightpool[m] yeah
# nightpool[m] not having content-negotiation does break doing content negotiation :P
# nightpool[m] ehhhhh
# nightpool[m] we have some link rel logic for atom stuff
# nightpool[m] and it's a huge pain
# nightpool[m] because you have to make multiple requests and parse the whole html body
# nightpool[m] it adds a lot of latency to the whole thing
# nightpool[m] and you have to worry about recursion, etc.
# nightpool[m] I dunno, the benefits seem pretty slim
# nightpool[m] because you already need something smart to handle the POST and GET stuff
# nightpool[m] also i don't know what you mean by "the CDN using communities". plenty of mastodon instances use CDNs
# nightpool[m] which ones are those?
# nightpool[m] i've never heard of it being a problem with cloudflare
# nightpool[m] plenty of mastodon instances are behind it
# nightpool[m] well, in practice, it works fine :P
# nightpool[m] i think there's maybe an argument for it as an additional thing
# nightpool[m] well, kind of?
# nightpool[m] the `id` of an activity *has* to be dereferenceable by spec
# nightpool[m] just because mastodon doesn't care doesn't mean that other implementation won't
# nightpool[m] what?
# nightpool[m] especially ones that, say, don't want to support http signatures.
# nightpool[m] everyone does it though?
# nightpool[m] they just don't need others to do it
# nightpool[m] what ids aren't dereferenceable in major implementations?
# nightpool[m] shrug
# nightpool[m] i think it's important that URI references are always content-negotiable (so if you say followers: "https:://whatev.er/followers" and someone tries to fetch the followers page, it doesn't take a bunch of requests and extra logic)
# nightpool[m] but saying that "if you have a URL that isn't already a json-ld document, you may find associated json ld documents using link discovery" would be totally fine
# nightpool[m] and support the omnibox search case
# nightpool[m] without really changing anything about the spec or for other implementations
# nightpool[m] i wouldn't be surprised, given that we already have that logic for ostatus
# nightpool[m] yeah, it looks like when we implemented activitypub we just got that behavior basically for free
# aaronpk and there are a lot of implementations of that https://github.com/w3c/webmention/tree/master/implementation-reports
# nightpool[m] it's different conceptually because it requires parsing a whole new document type
# nightpool[m] it's already mentioned in the OP i think: "[This is already implemented in Mastodon & Pleroma's MastoFE: they will check URLs put into the search bar for the <link rel> described earlier.]"
# nightpool[m] i think riking's proposal makes sense.
# nightpool[m] as long as we're careful that we're not making it broad enough that people get confused and put html URIs into as2 documents
# nightpool[m] if you want to replace that behavior with a useful behavior, it sounds analogous to ap inbox forwarding.
# nightpool[m] yeah
# nightpool[m] https://www.w3.org/TR/activitypub/#inbox-forwarding
# nightpool[m] handwavy
# nightpool[m] you can do a bunch of authentication solutions
# nightpool[m] and none of them were explored/standardized at the time of AP standardization
# nightpool[m] mastodon currently uses JSON-LD signatures
# nightpool[m] but we're not super happy with them and would be open to doing other stuff
# nightpool[m] i think resolving the URL is the most robust solution personally
# nightpool[m] that's a good point
timbl joined the channel
# puckipedia <nightpool[m]> but we're not super happy with them and would be open to doing other stuff <- i'd like some other signature thing that signs every object separately
# 
jaywink[m] salmon to the rescue \o/
# aaronpk PASETO https://paseto.io
# jaywink[m] works for diaspora and I believe zot too, if I'm not mistaken
# jaywink[m] hmm could be I was wrong about zot. doesn't seem to be very clear, there is a lot of text
# jaywink[m] not sure why JWS wasn't higher on the table. I think the general message was that auth should not be talked about and then mastodon did http signatures AND LDS
# jaywink[m] maybe auth should have been talked about ;)
# jaywink[m] LDS ended up on the table because you have to somehow verify the content is from who it says it is from when delivered via inbox forwarding.
# jaywink[m] yeah :)
# nightpool[m] jwt has a really bad reputation in the security community
# jaywink[m] jwt's are a bit short lived anyway
# jaywink[m] isn't that normally the case? I'm not an expert though. but signatures you might receive after days - maybe your server is offline and gets a really late delivery.
# nightpool[m] JWS is signatures
# nightpool[m] not jwt
# puckipedia ok so, imo: no JWS, no salmon
# puckipedia the issue with those is that they depend a lot on the compacted json serialization
# puckipedia the json-ld signatures normalize the json-ld document in such a way that they no longer depend on the @context, which is good because I have one that slightly conflicts with mastodon
# puckipedia I mean I could complain about secure scuttlebutt's signature thing
# nightpool[m] hmm
# nightpool[m] why is normalizing important though?
# nightpool[m] can't you just validate the signature and then process the document?
# puckipedia nightpool[m]: combination of two issues
# puckipedia primarily, that the JSON-LD representation may not be stored as-is, which means things could swap around
# puckipedia and also, conflicting extensions
# nightpool[m] mmm. still not quite seeing the issue
# puckipedia aka if you have
{"attachment": [a, b, c]} kroeg will return [c, b, a]# puckipedia this is all fine specwise
# nightpool[m] i guess the difference is if you're storing the signature and verifying it later, or verifying it at the ingress point and then discarding it
# puckipedia I would keep them
# nightpool[m] there's no reason your internal representation should come into signature verification at all
# nightpool[m] is my point
# puckipedia e.g.
{"type": "Like", "signature": ..., "object": {"id": "hxxp://remote/asdf", "to": "as:Public", "signature": ...}}# puckipedia nightpool[m]: I store the raw ogbjects I receive, but RDF-ized
# nightpool[m] right
# nightpool[m] but why not verify signatures at point-of-reception?
# puckipedia I will also
# puckipedia but why not keep them
# nightpool[m] before they're RDF-ized?
# puckipedia what's the use of discarding signatures
# nightpool[m] means you don't have to worry about normalization :P
# puckipedia like, the advantage of signatures is that you can embed the objects safely and the remote server doesn't need to pull it to verify it
# puckipedia nightpool[m]: ahahahahaha
# puckipedia so
# puckipedia secure scuttlebutt.
# nightpool[m] is that what they do?
# puckipedia well, here's the thing
# puckipedia their normalization is NodeJS's JSON.stringify
# puckipedia as in, that string is signed
# nightpool[m] i dunno, i'm just thinking out loud.
# nightpool[m] the JSON-LD processing is by far the most computationally intensive and fragile part of mastodon's security stuff right now
# puckipedia JSON-LD processing is pretty core to Kroeg and meow
# nightpool[m] is meow the new rust thing?
# nightpool[m] or smth else
# puckipedia no, it's a go activitypub server
# nightpool[m] oh, I haven't heard of it
# puckipedia it's pretty new
# puckipedia why is the json-ld processing fragile btw?
# nightpool[m] b/c it requires looking up remote contexts
# puckipedia I mean
# puckipedia it's either that
# puckipedia or embed the entire freaking context in each message
# puckipedia aaronpk: yeah
# puckipedia my contexts are "@context": ["https://www.w3.org/ns/activitystreams", "hxxp://server/-/context"]
# puckipedia I'd have dropped the AS2 context as well
# puckipedia but it breaks Mastodon
# nightpool[m] hxxp?
# puckipedia so Loqi doesn't try to connect to server
# nightpool[m] oh
# nightpool[m] fun thing I found out the other day is that all hubzilla servers use their own context namespace
# puckipedia oh?
# nightpool[m] https://gist.github.com/nightpool/740c67b73f59f5f787f0abc789457008, first json
# nightpool[m] apschema link changes between servers
# puckipedia ... *OW*
# nightpool[m] so technically you have to completely re-implement hubzilla extensions for every server you want to talk to
# puckipedia ow ow ow
# puckipedia anyways so far I have a slightly newer context.json
# puckipedia and well
# puckipedia it's ... small
# puckipedia and the "as:Public": null is to work around an AS2/AP spec issue
# nightpool[m] hmm?
# nightpool[m] this is the public collections thing?
# puckipedia yup. according to the json-ld spec, hxxps://www.w3.org/ns/activitystreams#Public has to be compacted into as:Public
# nightpool[m] why as:Public and not just Public?
# puckipedia because "Public" isn't defined
# nightpool[m] since it's unambiguous lol
# nightpool[m] ah
# nightpool[m] right right
# puckipedia oh dangit
# puckipedia it *is*
# puckipedia I'm not sure why it's not being compacted to that
# nightpool[m] lol
# puckipedia I think because it's defined as being an @id
# nightpool[m] how usable is new kroeg?
# nightpool[m] if I like, wanted to start building a client front-end on top of it?
# puckipedia ehm, should be fine enough for client-to-server things, not yet for server-to-server. there's no OAuth, but the rest should be fine-ish. also you need an older rust
# nightpool[m] what's up w s2s?
# puckipedia not yet implemented
# puckipedia I'm working on http signatures
# fr33domlover Hi everyone! I'm looking for advice on extending AP to project hosting
# fr33domlover Suppose there's a project hosted on server A
# fr33domlover I'm on server B and I open an issue targetting that project's issue tracker
# fr33domlover Normally in AP, I host the issue I created on my server B
# fr33domlover But then there's a problem: Server A decides on permissions! Which users are allowed to add tags to the issue, assign themselves to work on it, add it to a milestone and so on
# puckipedia so i'd fix this pretty easily
# fr33domlover And if I host the issue myself, server B doesn't have any control over what happens with the issue
# puckipedia server A creates the issue, then requests server B to create a Create activity pointing at A/object
# fr33domlover puckipedia, does the issue ID URL point to server A (where the project is) or server B though (where my account is)?
# fr33domlover Normally the answer is B, but,
# puckipedia the issue is on server A, the create activity is on server B
# fr33domlover When permissions are invlolved
# fr33domlover I'm unsure
# puckipedia {type: Create, object: hxxp://A/issue/1, id: hxxp://B/activity/22319239, actor: hxxp://B/user
# fr33domlover puckipedia, hmmmm what about the usual microblogging case like in Mastodon? Where do IDs of comments point, the server that hosts the post or the comment author's server
# puckipedia shrug, both'd be valid
# nightpool[m] normal comments are owned by the people making them
# nightpool[m] in a microblogging case
# puckipedia my concept of activitypub servers is that they are mostly just an object store, and then there's clients that talk activitypub c2s
# nightpool[m] because comments are on the same conceptual level as the things they're replying to, ish
# puckipedia nothing is stopping a server from hosting the object on their own server instead of hosting it on the actor's server
# nightpool[m] trustworthy attribution?
# puckipedia nope. the Create activity pointing to the remote serveris fine enough
# puckipedia for the rest, there's, hehe, signatures
# fr33domlover puckipedia, well the server keeps a copy anyway I guess
# fr33domlover The question is what the ID is
# puckipedia fr33domlover: the ID is wherever the master copy object is stored
# fr33domlover puckipedia, yeah I mean I'm wondering if the presence of permissions is a reason to put the created object on destination server rather than source
# nightpool[m] something something ocap
# puckipedia fr33domlover: you could, I wouldn't quite be surprised
# fr33domlover nightpool[m], suppose on a microblogging server I can control which users are allowed to comment on my post. Is that a reason to make comments be hosted on my server rather than on authors' servers the way it works in Mastodon afaik?
# nightpool[m] mmm it's a little complicated
# fr33domlover Because either way it doesn't prevent people from hosting comments my whitelist accepts
# fr33domlover So I'm wondering
# fr33domlover Which option is better
# nightpool[m] since you'd have to think about who enforces where the comments are created
# nightpool[m] like, what's to prevent someone else from hosting the comment?
# fr33domlover nightpool[m], well yeah that's what I'm saying. Like, either way there's no way to keep the fediverse in sync if some badly behaving server exists
# nightpool[m] this is why cwebber loves to talk about ocap
# nightpool[m] i dunno.
# fr33domlover Option 1: Keep comments in authors' servers but use signatures to verify which comments I have accepted
# fr33domlover Option 2: I host the comments
# nightpool[m] it feels like this whole project hosting thing is gonna be shitty until we figure out in-page social interaction anyway
# fr33domlover Yeah I want to examine ocap
# fr33domlover I was wondering if someone here had insights etc.
# fr33domlover About how to do stuff with permissions involved
# nightpool[m] i think that puck's idea is the right one
# puckipedia nightpool[m]: so I think pump.io is implementing this?
# nightpool[m] having the object be owned by the hosting server and the activity creating the object be owned by the user is a really smart seperation
# nightpool[m] it wasn't one i had thought of but it makes a lot of sense
# fr33domlover nightpool[m], yeah technically I guess that separation can work. But even then like you said, people can host stuff that I've rejected due to permissions. In the other option, my server simply keeps a copy of the stuff it has accepted. So it doesn't feel like a big difference, I wonder if it's worth it to violate the "standard" of you-host-what-you-created
# nightpool[m] that's not the point
# nightpool[m] the point is that later, if (say) a project owner wants to edit the issue
# nightpool[m] they can
# nightpool[m] if someone else wants to host the issue and hook it into your repository then ...... whatever?
# nightpool[m] it might show up in feeds, but it won't show up in your issue tracker
# nightpool[m] or whatever
# fr33domlover nightpool[m], hmmm good point
# fr33domlover jaywink[m], what do you think? :P
# fr33domlover When you have a moment
# fr33domlover I'm getting conflicting opinions ^_^
# puckipedia I feel like the most opinions are all directed into one direction at least
# nightpool[m] i think so far the only people who have given you opinions have agreed haha
# fr33domlover nightpool[m], oh I talked about this in another channel ^_^
dxtr_ joined the channel
# puckipedia right, found the related pump.io thing
# fr33domlover So essentially,
# fr33domlover Every activity I need to be able to authorize,
# fr33domlover I must host?
# fr33domlover Instead of the author being the canonical host
# nightpool[m] no i think it's the other way around
# nightpool[m] every activity you might want to edit later
# nightpool[m] you should host
# puckipedia fr33domlover: as long as you trust the other servers, you don't. but you can't trust the others
# nightpool[m] you can authorize activities in a bunch of ways
# nightpool[m] like Announce or whatever
# jaywink[m] I don't see how the ID of something I create could be on another server
# nightpool[m] easy
# nightpool[m] you send them the content
# jaywink[m] so that server can create anything on behalf of anyone and claim they created it?
# puckipedia no
# nightpool[m] no, that's where the Create comes into play
# puckipedia jaywink[m]: the as:object is hosted on the server, the Create itself is still on the actor's server
# jaywink[m] doesn't sound right still, feels like a dirty hack
# nightpool[m] why?
# nightpool[m] you Created the object, but it's not your object, it's an Issue in an issue tracker or something
# jaywink[m] what is the benefit?
# jaywink[m] why isn't it my object? I created it
# jaywink[m] just like a status message on a microblogging platform
# nightpool[m] Github allows project owners to close, edit, or remove issues.
# jaywink[m] sure
# jaywink[m] but that is just a definion matter in the GitPub or whatever it would be called extensions
# nightpool[m] definition how?
# puckipedia jaywink[m]: what if the hosting server refuses to close/edit/remove the issue
# jaywink[m] for example that "receivers should respect the activities from the repository they're targeting"
# jaywink[m] puckipedia: does it matter? if the repository closes their local object
# puckipedia there is no "local object". the issue is the object that is now remotely hosted
# puckipedia what if a server hosting an issue disappears
# puckipedia does that mean that the issue just, vanishes?
# jaywink[m] that sounds terribly inefficient to not cache objects locally
# puckipedia it's cached locally, yes
# nightpool[m] it doesn't matter whether it's cached locally or not
# puckipedia but you can't touch it because you're not the authoritative server
# nightpool[m] it matters who can actually edit the object that the other server is serving via http!
# jaywink[m] why not? if it's defined in the protocol
# puckipedia should
# puckipedia whta if a server believes it is the owner of the repo, but isn't
# fr33domlover On one hand, project author deserves to be in control of project's work plans. On the other hand, issue author deserves to own stuff they've published. Either way, the copy hosted by the project's server is what's useful to the project team. The question is, is it the authoritative copy or just a cache... :p
# jaywink[m] each server in the end will own whatever data they host
# jaywink[m] no protocol can change that :)
# puckipedia exactly
# puckipedia that's the point we're making
# jaywink[m] if I host the linux kernel, I m in control
# puckipedia yes, but you aren't the canonical host
# jaywink[m] I can close all the issues sent to my server, even if the ID's point elsewhere
# fr33domlover Logically when you open an issue, the project team should have control. You're welcome to post versions of it for fun like Mastodon toots, but, project team hosts their copy of the issue you opened and that's the copy that matters to the project
# puckipedia jaywink[m]: you can make changes, but that won't change what other people's kernels look like
# puckipedia and I'm not gonna trust your server to send me the proper commits, I'd validate with the server that owns it, aka linus's servers
# jaywink[m] exactly. that is why this works
# puckipedia so even if I close the issue, other servers will verify with the server that hosts that issue, which says "yeah it's still open"
# jaywink[m] if I post an issue to linus's server, the object ID imho should point to me
# jaywink[m] but linus can close it or rejct it
# jaywink[m] and it will not show in the official linus server
# jaywink[m] but it will show on mine maybe
# jaywink[m] but who cares?
# puckipedia ok so
# puckipedia now we have a malicious server, which spams issues
# puckipedia the official server has it blocked
# puckipedia does that mean all other servers show ten thousand spam issues
# nightpool[m] how do you tell the difference?
# puckipedia between spam and not spam?
# jaywink[m] depends what the protocol says. maybe the protocol says "trust only issues posted from the repository"
# jaywink[m] inbox forwarding
# nightpool[m] no sorry that was @ jaywink
# saranix not
# saranix depends on the impl permission paradigm
# saranix protocol does not specify
# saranix but practically
# fr33domlover Another possibility: Issue is hosted by author but there's a new Sign activity where the project team can GPG-sign stuff they have accepted
# fr33domlover (according to permissions etc.)
# puckipedia fr33domlover: ... no
# jaywink[m] ah, but it could. we're talking about extensions on activitypub, there is possibility to define there
# puckipedia that'd be chaos
# saranix if I'm on bloggosoft, and spamco.com puts out issues that are blocked by linux.org, but I am friends with spamco.com, I will probably still see spamco, because I have permissions for them and they deliver directly to my inbox
# nightpool[m] you don't even have to be friends with spamco for that to happen
# nightpool[m] they can just deliver directly to all the inboxes they care about
# saranix but if my software is set to block randos
# nightpool[m] eh
# nightpool[m] what instances are actually whitelist in practice?
# nightpool[m] very few because it hurts the network
# saranix hubzilla
# fr33domlover jaywink[m], note that creating remotely isn't against AP - you can even make a CreateOnDestination activity to be clear the object is to be created on the destination server
# saranix diaspora?
# fr33domlover It's not the way freely posted stuff is working
# saranix I know it doesnt speak ap, but
# fr33domlover But it doesn't violate AP
# saranix even if there weren't impl that currently do that, that doesn't mean anything anyways
# puckipedia and yeah, I feel like locking down as:inbox is deifnitely a valid implementation strategy
# saranix puckipedia++
# puckipedia you could say that mastodon even does it
# fr33domlover puckipedia, why would the Sign activity create chaos? Suppose I'm a project member, I browse an issue hosted remotely, my client verifies the signatures and I can tell my server has accepted all the stuff I see etc. Hmm I guess a posible problem is, what if some other server fails to notify my server on some relevant activity, and I don't see it in my client - so I can't tell there's some missing
# fr33domlover unverified permission-violated activity out there that other people do see :p
# puckipedia fr33domlover: use inline signatures on the objects instead
# fr33domlover I guess the create-on-destination idea may be the best
# puckipedia the remote server owns an object that is signed by the user?
# jaywink[m] fr33domlover: I do fail to see why though. To me this is not in the spirit of decentralization or federation but trying to follow a centralization pattern
# jaywink[m] the author of the object would basically only be the creator, but the object would not be theirs
# fr33domlover jaywink[m], it still is totally in the spirit of federation!! Think about it like this: A repo hosts and controls its issues and MRs and commits and whatever other assets, but people can still open issues and MRs and comment and make project teams etc. across servers
# jaywink[m] sure the protocol could say "please respect the creator when receiving edits", but it feels like just a hack
# fr33domlover When I envisioned federation for my forge project I never thought about people hosting their issues and MRs etc. to be honest
# saranix
{ type:[Create,Add], object: {obj}, target:https://remoteserver/appropriate/collection/" }# fr33domlover It's not a requirement for decentralization
# jaywink[m] the repo always controls their issues and assets, that can't be changed by anything
# fr33domlover jaywink[m], think about a repo like a post: I create a post, I control it. Other people can propose changes but I control and manage it on my server
# fr33domlover I understand what you're saying
# fr33domlover But hosting repo stuff all on the repo's server doesn't ruin the decentralization
# saranix the way things are now, issues belong to a fork. It is interesting to think about issues that belong to all forks collectively though......
# fr33domlover Think of "repo" as the atom rather than "issue/MR/comment"
# nightpool[m] i think an issue is a valid atom
# nightpool[m] but not an individual comment within that issue
# nightpool[m] and even though someone "opened" the issue, really they just made the first comment on it
# jaywink[m] well, not in github/gitlab etc world
# nightpool[m] no, i think that the mental model is still correct with github
# nightpool[m] consider that the owner of the repository can edit the issue's text, title, categorization
# jaywink[m] no, on github the author can edit and close the issue
# nightpool[m] and the person who opened it can't even re-open if it gets closed
# nightpool[m] i'm aware
# fr33domlover The point is that it should be flexible: In project X any user can open an issue, in project Y only project members can. And so on
# saranix "and the person who opened it can't even re-open" <- that would be impossible to enforce... if my software allows it, and my friends reopen, I'll still see it as open, even if your project ignores it]
# fr33domlover I mean, people can post toots that looks like issues on project Y, but, to the project team they don't exist
# nightpool[m] saranix: again, not if the issue is hosted on the server that hosts the repo
# nightpool[m] i think what puckipedia was saying about servers disappearing makes sense here as well. If someone's server goes down, should all of their issues disappear?
# saranix "toots that looks like issues" <- I was wondering about this for a diff project... how would I allow mastodon users to post complex objects that mastodon knows nothing about? some kind of magic markdown?
# jaywink[m] the server hosting the repo or issue tracker always has the final say
# nightpool[m] make mastodon a c2s server lol
# nightpool[m] jaywink: not if they don't have authority over the url
# nightpool[m] that's the ""final"" say
# jaywink[m] if I browse to git.linux.org which is an activitypub based code hosting platform and browse issues, it will have final say, no matter where the objects point to
# fr33domlover Either way repo's server can display its version of an issue, but yeah when the actual issue ID URL is elsewhere, people will find it and see some different version that the project team may disagree with
# jaywink[m] just like I can delete remote posts from my server and they will be gone
# jaywink[m] not from the remote
# jaywink[m] but from my server
# jaywink[m] and if the protocol defines, and I delete a comment, from any remote servers that respect my authority
# jaywink[m] the key is defining who has authority. in this case, the repository
# nightpool[m] jaywink: imagine that you're using an AP client, and you request git.linux.org/issues. It says it has 50 issues: ["https://nightpool.club/myissue", "https://jaywink.com/issue1"]
# nightpool[m] what happens when I start serving different issue objects to different people?
# fr33domlover jaywink[m], say you browse git.linux.org and it's a JS app running in your browser - where does it GET issues from? An informal cache they keep, or does it GET the actual issue IDs to fetch the data? What if someone browses those ID URLs and sees stuff the repo team disagrees with? How do they tell that content hasn't been authorized by repo team
# saranix anyone have any thoughts on servers originating complex objects that the originating software doesn't understand?
# nightpool[m] nightpool.club could say "fuck the developers and fuck this project!!!" when anyone who isn't a linux developer requests it
# puckipedia saranix: shrug, Kroeg handles it fine
# nightpool[m] saranix: that's what the c2s api is for
# jaywink[m] ah well, now we're talking c2s
# jaywink[m] I'm talking s2s :)
# nightpool[m] it works fine if you think if AP objects as opaque LD data. it breaks if you want your server to have application logic associated with it
# saranix puckipedia: I mean like if I have a {http://custom.example/foo" object type, with 2 fields, "something", and "otherthing", and they have special meaning on my site, I want people to be able to create these objects from on their home mastodon site
# fr33domlover saranix, on one hand there's c2s, on the other hand do we want servers that just transparently accept any activity coming via c2s?
# puckipedia saranix: yeah, kroeg is fine with that
# fr33domlover I'm unsure tbh
# nightpool[m] jaywink: i'm still talking about s2s!
# saranix puckipedia: "fine with that", you don't understand
# saranix puckipedia: how does someone craft their mastodon post to look like a "customfoo" object
# puckipedia saranix: it will just assume it's a plain non-special activity, and host it, publish it, run the normal privacy rules
# puckipedia oh right that
# puckipedia yeah, idk how mastodon would implement it
# puckipedia possibly "not"
# nightpool[m] mastodon would implement it by implementing the c2s spec
# jaywink[m] nightpool loves systemd: then I don't understand the problem
# saranix I don't want to rely on mastodon or anyone else implementing, that's the whole point
# saranix I want anyone from any activitypub software to be able to create "customfoo" objects
# saranix without their software knowing how
# jaywink[m] has had a few beers, so possibly is not at his best
# puckipedia saranix: as in, they need to handle creating flexible objects, which mastodon can't do
# nightpool[m] saranix: you can't do something that your server forbids you from
# saranix users don't GAF
# saranix they will want to do this
# saranix they don't care about technical whatwhat
# fr33domlover saranix, I like that idea too! But we need to think whether it's safe to just accept any activity you create on the client
# fr33domlover What if some stuff has extra logic associated with it
# nightpool[m] no. i'm trying to say deeper then that. if I try to go post "fuck you!" on mastodon, and it has a swear filter, then there's nothing i can do about that
# fr33domlover Like permissions
# nightpool[m] i have to use a different software
# saranix That's why I suggested some kind of magic markdown syntax
# saranix that lets you create objects from plaintext
# nightpool[m] mastodon could ban it
# saranix they could
# saranix stop being so negative
# puckipedia saranix: .... what exactly are you trying to do
# puckipedia like
# puckipedia
{"type": "Note", "content": "-- magic stuff here--"}# saranix puckipedia: yes
# puckipedia I mean, the whole point of activitypub is that you can do
{"@vocab": "http://custom.example/foo#", "type": "CustomObject", "something": "a", "otherthing": "b"}# saranix yes but there is no software that even remotely supports that right now
# saranix I need something that *works* *now*
# saranix not some future spec that relies on cooperation that will never come
# puckipedia this isn't a future spec
# saranix custom vocab
# saranix if the custom vocab doesn't exist yet, it's future ;-0
# nightpool[m] i'm so confused
# nightpool[m] i'm not trying to be negative i'm trying to say your usecase makes zero sense
# nightpool[m] you have to have some future spec to write your magic plaintext thing!
# saranix nightpool[m]: "your usecase makes ]zero sense" just because you don't understand what I'm saying doesn't mean I'm not making sense
# fr33domlover I have a use case for saranix's thing: I want to open an issue on some repo, and be able to do that from my Mastodon account instead of opening a 2nd fediverse account (since I don't want to open repos, just open an issue that's all)
# saranix fr33domlover: precisely
# puckipedia saranix: https://gist.github.com/puckipedia/45e15430239e4a4de2026c83585707f5
# nightpool[m] fr33domlover: right. and that's what the c2s api is for
# puckipedia saranix: I see nothing future here
# saranix nightpool[m]: no c2s even exist right now, that's not a solution
# puckipedia (I wanted to do @vocab, it broke things)
# nightpool[m] saranix: plenty of c2s servers exist
# fr33domlover nightpool[m], but would it be safe, if Mastodon servers blindly let *any* activity through? Just wondering
# nightpool[m] fr33domlover: yes?
# saranix if a server says it supports activitypub, and mastodon says it supports activitypub, they will expect that they will be able to use their mastodon to create the other type of posts without signing up to a whole new site. otherwise what is the point of decentralized? users will be very pissed.
# jaywink[m] fr33domlover: I still don't see the problem. just post a
{create: {issue}} to the target repo# puckipedia saranix: exactly, and I'm disappointed that this isn't the case, and that most people just implement the bare minimum
# fr33domlover nightpool[m], hmmm ok semi related question: If I create an issue, repo's server rejects it (I'm not allowed to open issues there) - does my server still host the Create activity or does it discard it
# nightpool[m] saranix: i don't think users expect that and I don't think that "create the other type of posts" makes any sense to a normal user
# nightpool[m] if they sign up for a mastodon account they expect to be able to make mastodon posts lol
# puckipedia huh, I thought the default flavor text mentioned activitypub
# nightpool[m] Anyway, if mastodon thought users expected that then they could support the c2s api like many servers here do https://activitypub.rocks/implementation-report/
# saranix nightpool[m]: you clearly don't have experience with the users I'm talking about. I do. If I said to you any of the stuff you keep saying, they would get angry with me that I don't get what they want, and they will simply walk away from the business relationship e.g. lost customers. That's not acceptable. Customer is always right.
# saranix *said to them*
# saranix I understand your point of view.
# saranix It's not me that needs convincing.
# saranix It's the users, and they are unconvincable. Period.
# nightpool[m] that's an extreme user-hostile attitude to have
# saranix They want what they want, and it's up to us as technologists to give it to them..
# saranix nightpool[m]: "custoemr is always right" is user-hostile? you mean the users are hostile?
# nightpool[m] Well, i don't get why you came to us to grind your axe about mastodon's supposed bad treatment of it's users
# nightpool[m] no i mean that treating your users as unthinking forces of nature that can never be reasoned with is user-hostile lol
# saranix nightpool[m]: no one said anything about mastodon's users
# nightpool[m] what is this use-case about if not for mastodon's users?
# saranix nightpool[m]: have you never run a business? or been a sys admin?
# nightpool[m] users are people just like anyone else and saying that technology is magic that can never be explained to them is blatantly disrespectful
# saranix nightpool[m]: telling them that they can get what they want if all they have to do is x,y,z or must use other software, or must sign up[.... that's not understanding what they want in the first place
# saranix why don't you get it?
# nightpool[m] anyway, you said "[users] will expect that they will be able to use their mastodon to create the other type of posts without signing up to a whole new site"
# nightpool[m] that's "mastodon's users"
# saranix I'm done with you, I called for ideas, not bullshit "it doesn't matter" excuses and fighting.
# saranix nightpool--
# nightpool[m] k
# puckipedia ... wow you can do that
# puckipedia nightpool[m]: I see this more as a generic thing, where someone registers with an AP-compatible server expecting it to just work
# saranix puckipedia: you get it :-)
# nightpool[m] puckipedia: that assumes users have a mental model of what AP is
# puckipedia nightpool[m]: it comes up kinda quickly because of the federation thing
# saranix and yet you want them to know what AP C2S...that's not having a mental model?
# fr33domlover saranix, btw interesting point: Mastodon limits by default to 500 chars. I guess if it accepted any activity, you'd still want some size limit on the objects etc.
# saranix fr33domlover: oh yeah, forgot about that...hopefully 500 is big enough though
# puckipedia I wonder if I should set up patreon/whatever for Kroeg
# nightpool[m] puckipedia: i'd contribute
# puckipedia mmm
# puckipedia I need to figure out how it works taxwise
# puckipedia like, it'll probably go to sole proprietor
# saranix fwiw, hubzilla used pseudo-bbcode for this e.g. [customobj][meaningful=something][/customobj] but then people complained and it got moved to proper json metadata attached to the post, but then that still requires all involved servers to have the same plugin enabled to be able to understand that data... which is kind of what we are trying to avoid here
# nightpool[m] puckipedia: most patreon campaigns are "Support this person creating internet stuff!" for flexibility and stress reasons.
# nightpool[m] and people don't generally seem to have a problem with that
# nightpool[m] A lot of feedback i've seen when people have gotten stressed out over not being able to provide enough content for their patreon or do enough things to feel like it "counts" is "We're supporting you, not the product"
# puckipedia nightpool[m]: yeahhh, I'd probably say "weird social networking stuff"
# puckipedia at the same time, I'm slightly scared if Kroeg is far enough to dothis
# puckipedia I shouuld probably finish auth, federation, and add a mastodon api wrapper
# puckipedia also I need to figure out if I can offer like, hosting, for patreon rewards
# puckipedia probably not, I can fix that issue though
widowclip joined the channel
# widowclip Can I toss out a hot take regarding the issue-tracking discussion earlier?
# widowclip Read the logs on the indieweb thingy
# saranix lol
# puckipedia widowclip: ... go ahead?
# widowclip As a project owner I feel like I should own my repository and that includes my issue tracker. Anything submitted there I would consider a contribution, and hence ownership forfeited by the author. Therefore, I would suggest requiring issues to live on the server hosting the projectt
# nightpool[m] fwiw we had this whole same argument last time we talked about this lol
# saranix windowclip: I think most of us agree on that
# nightpool[m] it's in the meeting logs for i think the second-most-recent socialcg meeting
# widowclip The meeting logs are not posted
# widowclip most recent is in june
# nightpool[m] that's also the most recent meeting
# widowclip Oh, was one skipped?
# nightpool[m] we've been pretty off and on because of cwebber2's move
# nightpool[m] and a general slowing down of interest
# widowclip Also my bad, my understanding of the discussion it seemed assumed that the issue author had ownership of their issue. Didnt realize my take was in fact lukewarm atbest
# saranix there are other types of data where the answer may be different, but in the case of git, each repo owns their fork and each fork has their own issues, that's just the way git works, so anything different would be something new. But other things, the reverse is true perhaps
# nightpool[m] that's the start of the discussion we had last month on the exact same issue we just rehashed here lol
# saranix lol
# nightpool[m] widowclip: yeah it seems pretty evenly split between people who think that the issue author should have ownership and that the repo should have ownership
# widowclip I think part of the discomfort is that on one level federation is really just a common api for servers to chat about whats been going on in their respective silos
# saranix I think it goes much deeper than UX with git. The git data structures themselves, the issues are part of the fork, they are data inside the fork
# puckipedia -> bed
# widowclip obviously that enables the servers to do things that we also call federation that is not possible in the content silo model but like still
# nightpool[m] waves goodnight to puck
# widowclip I dunno how to do this third party stuff in irc but have a nice night!
# widowclip person*
# widowclip Neat. Thanks
# widowclip Is the federated community trying to make a single sign-on solution where you have one account that acts on your behalf or are people pretty comfortable retaining one account per service model
# widowclip And by federated community I mean people in this chatroom who wish to respond
# saranix I'm working towards the former model. indieauth is an example of a community in that model
# saranix s/in/favoring/
# widowclip aaronpk: you also administrate your own domain correct?
# widowclip host your own content, and all the AP things that you do?
# widowclip Do you think that users who are not comfortable doing that could be given that as a service?
# saranix aaronpk: oh? you needed a separate mastodon account?
# widowclip Thank you I will look at that. I am trying to understand how federated services work, and particularly how they work for a variety of people
# saranix aaronpk: and you achieved that, yes? mastodon did not get in the way of that?
# widowclip aaronpk: I have actually seen your website, it is an incredible demonstration, really great work.
# widowclip Does micro.blog have a very general AP client? I feel like a client which can create and POST arbitrary objects would be useful.
# saranix I hope that a client which can create and POST arbitrary objects will become the norm eventually...
# saranix solves a lot of problems
# saranix shouldn't be hard to make a ux that you just paste a context into, it fetches it then creates appropriately typed form fields...
# widowclip saranix: i feel like there is a UX gain in specializing the content you make. If I want to read and consume 500 character content then mastodon (or halcyon) is optimized for that. If I want to consume video then a peertube client provides a nice interface.
# widowclip Maybe I point both at a domain where I have a user whose inbox is full of both kinds of content, and they each give me a different view into my AP world
# saranix true
# widowclip I think that is the great promise of AP c2s
# saranix yeah, I started writing a c2s in that idea about a year ago... I forget how far I got. I think I got held up on ld-sigs
# widowclip You host your user with some server you trust, imho probably running software more general than mastodon or peertube, and then can point any client you like at it. Hell, run a matrix instance too.
# aaronpk here's a few screenshots of some different views on the same data https://github.com/cleverdevil/together/
# widowclip Neat
# widowclip Although, now I am just thinking out loud but I guess the specialized server software has an important use case: say you are a twitter celebrity with a million followers who pretty much only tweets, I think the best way for the federated world to host you is on your own instance, running mastodon to take advantage of the shape of the data.
# widowclip Or maybe the vlogbrothers (are they still around?) want to create an online community centered around vlogging, they could host a peertube instance for themselves and their followers. I guess the biggest hurdle then for that category of use is they need to hire a Sys Admin
# saranix I think the most interesting part of it is the psychology. Like there are certain site layouts that are really popular, that I just can't read. Twitter, mastodon, etc. among them. So therefore I am disenfranchised by being cut off from this information, or by not absorbing it the same way as the rest of society. The other option is to try to conform, try to make myself think like everyone else so it isn't so visually jarring...
# saranix So you see, in a way, having just 1 way to view information, is really discrimination of sorts...
# widowclip Not to mention users whose disability/accessibility issues interfere with their consumption of content
# saranix yes... it is as true of recognized humanodiversity as unrecognized
# widowclip I think that is the thing, it is almost impossible as a designer to account for every possible human, so we must empower users to shape their own experiences whenever possible.