saranixcan we also add using ActivtyPub for chat? It occurred to me that matrix.org is actually a more verbose and overly complicated protocol compared to AP (mostly thanks to http-sigs, actor objects, and fetchable room uris)
ajordan!tell fr33domlover the wiki can be really dumb with passwords. try a super simple one, I'm talking like 16 characters, alphanumeric only. that should eliminate any password complexity issues.
cwebber2we got an offer already today. We are hoping for one other to also come through today but we will see... one way or another it looks like it's happening.
Loqifr33domlover: ajordan left you a message 10 hours, 47 minutes ago: the wiki can be really dumb with passwords. try a super simple one, I'm talking like 16 characters, alphanumeric only. that should eliminate any password complexity issues.
ajordaneprodrom: hi yeah my name's Evan Prodromou, I'm one of the coauthors of the AS2 spec and also one of the contributors to pump.io, a distributed social networking project
aaronpkeprodrom: users can definitely be actors. issues probably don't need to be followed int he same way, but users and projects would make sense to be actors.
ajordaneprodrom: so I think probably next steps is, I would do this in our GitHub repo and then I'll collaborate with sandro and rhiaro to get it pushed to W3C servers
ajordaneprodrom: the one thing is, I'd like to make sure we do as many of these as possible at once, so I'm gonna do a last pass over AP, add them to the context and ask sandro/rhiaro to do the push
ajordanaaronpk: anyone have thoughts about that? sounds like this is essentially a bugfix so I'm inclined to just let the editors roll with it since it's not creating anything new
ajordanaaronpk: before we go back to fr33domlover's questions, does anything else have anythign to talk about? otherwise I think we should just go back to the original questions
aaronpk... citation needed, but I think pump.io should accept anything it doesn't recognize, so as long as you provide some sort of sensible alternative content, like a fallback description in summary, then it should display
aaronpk... it might not show up in the pump web UI or clients, i'm not sure, but you could use a pump account. like if you had a client that displayed issues you could use your pump account
aaronpk... the spec says you can treat the data as plain JSON, so do implementations usualyl understand JSON-LD? would that be a problem? or can I trust them to accept what they don't understand
aaronpk... what has happened in real life is all of the implementations have converged on this authentication scheme where server-to-server people use HTTP signatures and linked data signatures, so all implementations are full JSON-LD processing or they have a corner where they care about LD and the rest they treat it as plain JSON
saranixhmm... I suppose the same applies to my chat presense question... so if someone is "following" the room actor, they will get objects like { summary:"@foo is now away"}, but what should the type:{} be? Should it be a top-level activity of some kind? Since type:Add, object:type:{away status", etc.} seems kinda overly verbose
aaronpkajordan: if someone is consuming JSON-LD you can treat it as plain json except for the signatures. if you're producing it then you have to worry more about JSON-LD
aaronpk... I had this thought, suppose a project is an actor, since a project is part of the application itself, it's not a person, it doesn't need to GET its own outbox or POST to its inbox
aaronpk... so the only things you need from an outbox and inbox for a project is people need to be able to post to an inbox to send changes and get from the outbox to see events
aaronpk... in regular REST applications you post to the object to make changes, so if you use the same URL for the inbox as the actor then you can use the content-type header whether you're receiving plain JSON or HTML form input, it all goes to the same URL
aaronpk... it is worth noting that in activitypub, the client-to-server stuff is totally separate from server-to-server, so if you wanted to, you could implement a "regular" rest client-to-server API and then use activitypub for server-to-server.
saranixBUMP: so if someone is "following" the room actor, they will get objects like { summary:"@foo is now away"}, but what should the type:{} be? Should it be a top-level activity of some kind? Since type:Create, object:type:{away status", etc.} seems kinda overly verbose
trackbotSorry, aaronpk, I don't understand 'trackbot is slacking so I think i'm gonna have to generate the minutes manually'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
trackbotSorry, aaronpk, I don't understand 'trackbot didn't run so we don't have the nice minutes so i'll just paste my chat logs'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
saranixmelody: yeah, but the thing that made me think it's worth doing is a colleague has this tagline on their emails for some app that boasts itself "view all your emails as a chat", which made me realise, it's all about how you Style it...
fr33domloverIt's interesting to use AP for chat, however look at XMPP and Matrix etc. and see if they have stuff that AP can't do, something essential to IM
saranixfr33domlover: I'm a researcher, I've been familiar with both XMPP and Matrix as they evolved, and I'm making the point that they SUCK compared to AP
Loqitantek: fr33domlover left you a message 4 days ago: Yeah but it takes some discussion, it's hard to follow a slow paced async conversation on IRC, it needs something where messages are recorded like a mailing list (or just email when it's 1-on-1)
ajordansaranix: I feel like it would be a better idea to do things the "right" way in AP, even if that means sending full objects, and then tack on extensions to make stuff more efficient
ajordanyou could even experiment with hyperefficient transport, I know the XMPP people were at some point experimenting with a binary encoding of their XML
saranixajordan: but "away status" isn't necessarily a property of AP actors. it's an extension itself, so we could just as easily make it it's own first-class object and it would still be the "right" way
melodyi can't think of how you'd model chat with AP, maybe you could do one-on-one chat but modeling rooms, permissions and moderation would be a problem -- this really doesn't work well with the follow semantics
saranixmelody: none of the things you mentioned are different for "chat rooms" than they are for "forums", and no one is claiming that AP can't do forums
ajordanI seem to recall that there was a *lot* of optimization so it was a lot better than just 1%. I have absolutely no idea if I'm remembering right but I think they did it so that both sides knew the schema and therefore you basically had to send the data and literally nothing else
tantekajordan, it smells like tunnelvisioning akin to bikeshedding - profiling is hard, so let's optimize *part* of the problem without understanding if it actually contributes anything noticeable to the problem. Happens a lot in dev/engineering/standards circles.
ajordanit's also more complicated than it seems because a lot of the XMPP folks are concerned about mobile perf, so there's stuff like well, if data is smaller you don't have to wake the radio for as long
ajordantantek: definitely agree that tends to be a problem. I don't know for sure if it was in XMPP's case. FWIW they *did* get the low-hanging fruit before that
ajordane.g. a big battery killer was setting up and tearing down TCP sessions on network changes so they've got a session resumption spec that's been around forever
ajordantantek: again I don't know the details and don't want to try to defend something that for all I know never even made it to an official standard - just relaying what I remember
melodyi just think the scope of the changes you would need to make to do chat *well* on AP would probably make it resemble an actual chat protocol and would also make proper interop pretty much out of reach
saranixWell so far I have all the basics figured out with no major problems. The worst being the status summaries being annoying, but my response to that is: Riot (matrix.org) didn't even add support to collapse annoying status changes until about 6 months ago, IRC has absolutely no solution for that and no one complains, and when Hubzilla federates to old versions of Diaspora, Likes also show up as annoying summary text, sso it's not like we're doing someth[CUT]
melodythat came out meaner than i meant it to but like, F/OSS has a serious ongoing long-term usability problem and I think major UX issues are an inevitability if you tried to implement chat over AP
saranixI happen to like IRC, and hubzilla. And Diaspora is passable, but certainly far superior to Mastodon. I find Mastodon to be grossly unusable, and yet it is super popular. I don't think you're being fair about what makes something popular.
saranix can we also add using ActivtyPub for chat? It occurred to me that matrix.org is actually a more verbose and overly complicated protocol compared to AP (mostly thanks to http-sigs, actor objects, and fetchable room uris)
@HongPong If you take a half hour to skim over this, that is really the key to the decentralized network. Protocol specification https://www.w3.org/TR/activitypub/ #activitypub #mastodon #gnusocial #indieweb (twitter.com/_/status/978859404169801729)
RRSAgent logging to https://www.w3.org/2018/03/28-social-irc
aaronpk ... what has happened in real life is all of the implementations have converged on this authentication scheme where server-to-server people use HTTP signatures and linked data signatures, so all implementations are full JSON-LD processing or they have a corner where they care about LD and the rest they treat it as plain JSON
trackbot Sorry, aaronpk, I don't understand 'trackbot is slacking so I think i'm gonna have to generate the minutes manually'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
ajordan s/saranix: /<ajordan> saranix:/