#social 2017-09-17
2017-09-17 UTC
jankusanagi_, xmpp-social and howl joined the channel
# 
xmpp-social [Takyoji] cwebber: under section 7.11 of the ActivityPub spec, I'm assuming "increment the object's count of likes" was intended to be "increment the object's count of shares" for the Announce activity; or is the current text intentional?
# xmpp-social [Takyoji] Also, for section 7.1.3, I assume 'from' is mistakenly in the sentence 'When an object is being delivered from to the originating actor's followers, (...)"
# Gargron cwebber: pleroma implemented custom emoji in ostatus https://gitgud.io/lambadalambda/pleroma/compare/03952a27600b0947c415a72655262eaa37804d23...7c82b8219734102ff24d9dc24226c08351e608cc i'm assuming we could do something similiar, for example with
{ content: 'Test :foo:', tag: [{ type: 'Emoji', name: ':foo:', href: 'http://example.com/foo.png'}] }# Gargron do you think that's reasonable? probably would be a legit json-ld extension
# erincandescent Gargron: For emoji i'd be very tempted to just do <img src="foo.png" alt=":foo:"> or maybe <img src="foo.png" data-emoji="foo">
# erincandescent This has the nice benefit of clean fallback for unaware implementations too
# Gargron no, i dislike that because i will not render <img> tags inline, they'll get sanitized out. mastodon doesn't do hotlinking
# erincandescent Well, OK, but you can detect that they're an "emoji img" (using the data-emoji thing) and handle them however you want?
# erincandescent And your sanitizer should replace the image with its alt text for fallback anyway
# Gargron transforming html is not a pleasant activity
# Gargron i'd rather have structured data
# Gargron from which to generate final html
# erincandescent I mean, you can do whatever you want, but the content field is html
# Gargron so it is, and you may put <img> tags there, but i won't show them. we're talking about custom emoji which implies a certain level of additional business logic required, therefore i would prefer a json-ld extension and metadata
# erincandescent To me at least, emoji are content and belong in the content :/
# saranix I have to agree with erincandescent
# saranix really, your parser should just grab the 😅 and if you want to ascribe some sort of semantics to that, do it yourself
# Gargron but whatever
# puckipedia I agree with erincandescent here, for one important reason: the ":foo:" syntax is not actually standardised anywhere
# puckipedia and alternatively, you don't embed standardised emoji as :foo: either. those are the unicode characters
# puckipedia and I agree that image fallback is better than text fallback
# erincandescent Gargron: But there is text fall back - its' the alt text!
# Gargron the prior art here is not unicode emoji, but twitch and discord emotes. when they don't work (e.g. you're not a sub to the right channel) they appear as plaintext/shortcodes
# erincandescent I don't know about Discord, but for Twitch that's because Twitch chat is plain text
# erincandescent AS2 is not plain text
# puckipedia discord is basically plain text also
# Gargron yes
# Gargron mastodon is basically plain text also tho
# Gargron you can't imagine how frustrating we make app dev's lives by forcing them to handle <a> tags for usernames/hashtags in our posts
# erincandescent But ActivityPub is not. E.g. you'll get lots of HTML coming across when pump.io joins up
# erincandescent (...I once embedded a YouTube video in a pump.io post!)
# puckipedia Gargron: "mediaType": "text/plain" :P
# Gargron yeah i might eventually switch to that or maybe "source" property, i keep using text/html because ostatus forced us to
# puckipedia yep
# puckipedia OStatus content has a type attribute
# Gargron yeah sure but gnu social used text/html
# erincandescent Gargron: I can't say the HTML ever caused me any issue a s a client dev
# erincandescent I just passed it to WebKit for rendering
# puckipedia Gargron: no reason not to use type="text" between Mastodons
# erincandescent mediaType doesn't apply to objects
# Gargron mastodons early design decisions were dictated by gnu socials status quo
# erincandescent oh wait it does
# Gargron anyway
# Gargron even if you pass it to webkit, you have to hook up the links in the rendered html to whatever opens profiles in your app
# Gargron you have to use the attached mention metadata to match href attribute to the url attribute
# Gargron its not pretty
# erincandescent They tended to go out to a web browser becasue there was no attached metadata, sadly
# Gargron yeah, see, that's not good ux
# erincandescent Though usernames embedded in posts were pretty rare on pump.io
# puckipedia also don't mentions in Mastodon drop the "@[hostname]" part anyways
# Gargron if you got the posts as plaintext with a standard syntax for mentions, you could just render your elements properly from the start
# erincandescent But I don't want to post in plaintext :p
# Gargron puckipedia: yeah, both gs and mastodon do this for the visible part of the link
# puckipedia Gargron: that assumes everyone will use @[nickname]@[domain] anyways
# Gargron well, the good thing about html is that you *could* use a different mention format, and as long as the href matches, it would work
# puckipedia erincandescent: text/x-org :P
# erincandescent gotta work out that href is a mention though
# erincandescent puckipedia: eww
# erincandescent puckipedia: also can't embed youtube videos in that :P
# puckipedia it's an example in the spec! :P
# Gargron as i said, its not a pretty task!
# puckipedia erincandescent: the mentioning processing is simple in my case - just try to retrieve it as an AS2 object lol
# Gargron mastodon uses microformats rel attributes to give the <a>s some meaning
# puckipedia (client-side, that is)
# Gargron but because gs and other things like hubzilla dont do that, its not reliable
# erincandescent Gargron: yeah, that makes sense
# Gargron another thing: we do the link preview card for toots, right? we look at the first link. because mentions and hashtags are links just like normal links, this leads to useless results. the rel tag helps us, but again, only mastodon instances attach it
# Gargron tldr html has some pros but also lots of cons
# erincandescent Gargron: So when I was working on Impeller, I did the link preview generation clientside before posting the thing if somebody shared a URL to the app
# erincandescent This is actually how the youtube embedding happened, iirc I scraped the twitter:embed meta tag or something like that
# Gargron that is no problem on the origin instance of the toot
# Gargron but link previews dont federate
# puckipedia "All Objects in [ActivityStreams] should have unique global identifiers." oh no; Link objects; aaaa
# erincandescent puckipedia: Links are not Objects
# puckipedia erincandescent: I know
# Gargron theyre all objects brent
# puckipedia anyways help Link objects vs just a url as string
# Gargron anyway i guess all i really need for my plan is an Emoji link type
# Gargron http://joinmastodon.org/ns/emojo
# Gargron is there a json-ld context generator somewhere?
# erincandescent Gargron: hmm?
# Gargron i am again not sure how that document is supposed to look
# Gargron i just wanna define a single type vocabulary
# puckipedia
{"@context":{"mastodon": "https://joinmastodon.org/ns#", "Emoji": "mastodon:Emoji"}}# puckipedia I guess
# erincandescent Or you could just do <"type": "http://joinmastodon.org/ns#emoji"> in the AS2
# erincandescent Though yes capitalization, types should be capitalized
# Gargron you suggest i use fragment URI for the emoji context? i was thinking it's best be a stand-alone extension
# puckipedia the context I made just kinda equals "Emoji" to "https://joinmastodon.org/ns#Emoji"
# erincandescent I guess if you were doing a standalone NS then it'd be something like "http://joinmastodon.org/ns/emoji#Emoji"
# erincandescent
{"@context": { "Emoji": "http://joinmastodon.org/ns/emoji#Emoji"}, "type": "Emoji"}# Gargron ok thanks
# erincandescent JSON-LD has Too Many Features
# puckipedia erincandescent: hm, if I were to store the activitystreams objects as triples, I have to generate blank node IDs for stuff like Link objects, and then transparently remove the IDs again :<
# erincandescent puckipedia: yup
# puckipedia even worse
# puckipedia if I do that it's really expensive to compare "ID to Link object" versus "just a URL"
# erincandescent Eh, isBNode(n) => n.startsWith("_:")
# erincandescent Or if you're storing as a URI, uri.scheme === "_"
# puckipedia but now, what if someone *does* give a Link an ID lol
# erincandescent you've already gotta cope with that :(
# erincandescent AS2 is too flexible
# erincandescent *flashback to ancient postings complaining about this*
# puckipedia lol yeah
# puckipedia if only JSON-LD had a way to define structure, except for types and properties
# erincandescent Way Back When I tried to get every property to be *either* Link or Object, but failed :(
# puckipedia :(
erincandescent joined the channel
# cwebber Takyoji: you're right re: 7.11 likes vs shares, please file an issue!
# cwebber Takyoji: likewise with the typo in 7.1.3
# cwebber Gargron: I think this would be a good topic for the SocialCG call
# cwebber Gargron: I wonder if rdfa markup or similar wouldn't be a good way to make it machine readable *and* embedded in the content
# cwebber but I don't totally understand what pleroma is doing (and don't have a large a mount of time to read through all that right now)... I'd love an explaination for tl;dr the source code
# cwebber oh, you're saying you aren't really using html?
# cwebber catching up slowly in convo and commenting in read-time ;P
# cwebber erincandescent: oh cool I didn't realize you wrote Impeller, nice
# cwebber ah, hm
JanKusanagi joined the channel
# xmpp-social [Takyoji] Idle unrelated thought: I wonder if it'd be a bad idea to use a signed int as the DB primary key for actors. Positive int if local, negative if remote. Probably nothing to be gained though.
# melody i'm just catching up too and i strongly prefer :blah: as a fallback for custom emoji, in a lot of, for instance, slack communities the words you use to insert the emoji are as important if not more important than the actual image, and the XMPP and IRC bridges, as well as the "disable emoji" setting all fall back to that, html isn't the best vehicle
# xmpp-social [Takyoji] cwebber: I assume it'd be best to probably hold off creating an issue over a single grammatical error until I probably have a few other minor corrections with it, or?
# puckipedia melody: though, those fall back to *text*
# puckipedia and disable emoji would be equal to just disabling images, which fall back to alt text, which falls back to :blah:
# puckipedia another point, why would you need to 'fall back' to a text variant of emoji
# melody disabling emoji and disabling images are not the same thing, and i think falling back to text is preferable
# puckipedia still. you can't really disable "emoji" normally, just custom emoji
# puckipedia why even make the difference
# melody you can if you transform unicode in the emoji range to their :text: representation and handle the image replacement elsewhere, which has been necessary for compatibility reasons historically and is necessary for consistency if you want more consistency across devices in the representations
# melody im gonna keep using slack as an example, but because slack allows aliasing multiple :blah: tags to the same image, there has also been a tendency for communities to overload the :blah: with meaning, so you might have an emoji that is say a picture of a trash can but you can make it show up by typing either :bad_day: or :trash_can:
# melody the text matters more than the picture
# puckipedia so why even have the picture at that point
# puckipedia also alt text exists
# puckipedia and another thing. the default mediaType is text/html, not text/html+customEmojiWithColonTags
# puckipedia I do not want to go parse HTML just so I can parse the proper colon tags out of it
# melody and i don't want to parse html just so that i can figure out which <img> tags are actually supposed to be emoji and do something appropriate with them
# puckipedia why would you need to? they will show up as proper emoji alreayd
# melody i need to if i want a user to be able to disable emoji, or custom emoji, without disabling all images
# melody and that's not really an absurd use case, there are people for whom images inlined directly into text content are distracting but who are fine with seeing image posts and images in the UI, or who need a larger font size and the <img> tags won't grow the image to the full line height and they'll be ugly, the text fallback might be the most pleasant user experience
# melody i really do think that treating custom emoji the way we treat hashtags or mentions is probably the best case scenario, you define the tag `:my_emoji:` you provide a link to the image and its up to implementations to generate the HTML to link or embed the image if they want to support them, all as more structured data
# puckipedia melody: actually. hashtags and mentions *are* already <a> tags in the content
# puckipedia so by that logic, this would be an embedded <img> as well
# melody then i misunderstood something in my reading
# melody or we're talking about different things
# puckipedia melody: curl https://icosahedron.website/@colon_three/3909593.json | jq .
# melody what is this for? if they're just links https://www.w3.org/TR/activitystreams-vocabulary/#dfn-mention
# puckipedia those are metadata
# puckipedia but I mean the actual "content", the actual html of the message
# puckipedia "content": "<p><span class=\"h-card\"><a href=\"https://mastodon.social/@Gargron\" class=\"u-url mention\">@<span>Gargron</span></a></span> does this mean youtube videos now? :o</p>",
# puckipedia but yes, I do think having a Emoji in the tags is good too
# melody i guess i made a bad assumption that the metadata would be used to generate the HTML for mentions & hashtags and not that the already-generated HTML would be being passed around
# melody but i guess having the structured metadata means i could -- in principle -- strip the HTML and regenerate it using the metadata if i want to / need to for some reason
# puckipedia yes
# puckipedia alternatively, Mastodon might be providing the plain text content as well later on
# puckipedia I prefer to *not* do any post-processing, which is why I prefer embedding the img in the content. because, I don't trust other servers to parse my custom emoji properly :P
# melody yeah i think i was misunderstanding the conversation, i'm still new ?
# puckipedia no problem :P
# melody looking at https://www.w3.org/TR/2017/CR-activitypub-20170509/#source-property what does "In general, clients do the conversion from source to content, not the other way around." mean, i'm not sure what "the other way around" is trying to imply
# puckipedia melody: imagine that source is in markdown, and content is in html
# puckipedia you basically always go from markdown to html, but why would you ever go from html to markdown
# melody is client being used very broadly there? like i'm not sure if this is implying something about client-server interaction and where the responsibility for doing that conversion is
# puckipedia it might apply to the previous sentence "to support future editing by clients"
# puckipedia anyways if you don't do the client->server part, you can just do whatever you want, I guess
# melody Yeah, I'm just trying to figure out what the obligation is.
# puckipedia if you are writing the client->server api, just keep the content/source as is, I guess
# puckipedia and if you build a client, allow the user to edit source if possible? though that isn't defined
# erincandescent Yeah, source is so that a client which doesn't edit with HTML can store its' source on the server. It's not really useful for server<->server interactions or recieving someone else's post
# puckipedia true
# melody I'm just thinking like, if I wanted a very simple client, I might not want to dereference all of my mentions/hashtags on the client side, so the source might have a mention and a tag in it, but I can't render the final HTML for the content yet
# melody I'm trying to determine if that's an allowed thing
# puckipedia assuming you control the server as well, you could assume that
# erincandescent Anyhow, I still quite like the idea of '<img src="https://example.com/emoji/foo.png" alt=":foo:" class="emoji">'
# melody the server has a lot more information at its disposal to handle that sort of parsing & processing
# puckipedia erincandescent: same
# erincandescent You migth be talking to somebody else's simple server which doesn't do that though
# melody sure
# melody is the server allowed to do that kind of processing though? or is a complex client just a necessity?
# erincandescent The server would be allowed to do a lot but not required
# erincandescent And it's very difficult to do it on incoming objects (especially if we envisage a future world where objects are signed by senders)
# erincandescent "Suspended Exceed Turbo X Session" oh no I left an xterm open
# erincandescent oops wrong window
# melody i guess for some context, i'm still trying to scope out whether activitypub is going to work for my needs, i haven't started writing my implementation yet & my interest in federation and the fediverse ends when it gets in the way of my other design goals which are primarily around communication based on informed consent & abuse prevention, ill happily set up a walled garden if need be, but im hoping not to need to
# melody so interoperability with other implementations is mostly a tertiary concern, i'm just trying to get a feel for in practice what the obligations/responsibilities are and how much flexibility there is around which components _can_ do what, leaving whether they should or whether other implementations will like it for the "maybe think about later" pile
# puckipedia ah. so you only want to use ActivityPub for federation?
# melody opposite -- i want to know if activitypub will be suitable for an internal implementation of what i need working with my client/my server with federation as a secondary or tertiary concern, but it would be nice to be able to interoperate
# melody i started by trying to work out what i would need to do to ostatus to make it work and the answer was "break it very badly"
# melody then i found out about activitypub and now i'm here
# puckipedia yeah, OStatus is a mess
# melody so basically -- if activitpub is flexible enough for what i need to do, even if i never do federation and none of my stuff works with anyone else's stuff because i have too many custom extensions and my junk's all weird, i'm okay with that on a personal level, i'm interested in not starting from zero on designing the client-to-server and server-to-server communication (if i decide to do the latter)
# melody i would *like* to play nice with everyone if possible i'm just not sure the degree to which that will be plausible yet, i'm still wrapping my head around everything
# melody i definitely see the logic now behind clients rendering the HTML to the content, i'm not sure whether i can trust other clients to do that, there are so many a11y and i18n implications -- will need to think about this more and go back to my feature list and start mentally remapping the concepts to activitypub
lambda joined the channel
# lambda hello
# lambda i'm implementing http signatures
# lambda but I just can't get the signature examples in the spec (https://tools.ietf.org/html/draft-cavage-http-signatures-06) to match
# lambda has anyone here tested them out?
# Gargron i wanna once and for all clear up that "custom emoji" is not at all the same thing as "unicode emoji", i keep hearing things like "custom emoji should be encoded as unused unicode codepoints or combinations". custom emoji is not "smiling face", custom emoji is, for example, "Keepo", a face of a person named Kappa but with ears of a dota hero named Meepo. you can't encode that as general unicode and the text is meaningful by itself
# Gargron and again, i dont wanna stick <img> tags into our status text output in the APIs and i fear all of the bikeshedding which is likely to appear in the PR i've opened
# erincandescent OK, but I suspect everyone else's impls is probably going to display your "meepo" emoji as :meepo: or similar...
# Gargron and that's fine imo
# lambda yeah i think so too
# cwebber Takyoji: up to you, I think it's ok to file multiple issues... if they're small they're easy to close! :)
# saranix lambda: yeah someone else had the same problem, we tested them and both came up with the same result that was different from the spec. Never field an issue (don't know how, and/or it's on github don't remember)
# lambda saranix: thanks
# lambda it's the salmon spec all over again
# cwebber hey lambda
# cwebber lambda: I just did that and bumped into the same thing
# cwebber I talked to the spec author
# cwebber there's an open issue
# cwebber the examples don't work in there because some fields were changed
# cwebber so it's not you
# cwebber lambda: but maybe we should see if *our* implementations match
# cwebber lambda: (ie, the examples in the spec are broken and its a known issue)
# cwebber lambda: https://github.com/w3c-dvcg/http-signatures/issues/21
# lambda ONE JOB
# lambda oh well
# cwebber lambda: you just did the signatures with the spec's private key right?
# cwebber could you paste me the output?
# cwebber let me see if it validates here
# lambda the first one for default is
# lambda jKyvPcxB4JbmYY4mByyBY7cZfNl4OW9HpFQlG7N4YcJPteKTu4MWCLyk+gIr0wDgqtLWf9NLpMAM imdfsH7FSWGfbMFSrsVTHNTk0rK3usrfFnti1dxsM4jl0kYJCKTGI/UWkqiaxwNiKqGcdlEDrTcU hhsFsOIo8VhddmZTZ8w=
# cwebber lambda: ok hold on, I'm pulling up my test-file for this
# lambda i got that with ruby, erlang and the openssl binary
# cwebber lambda: sounds like it's probably right :)
# cwebber lambda: but let me chech here
# lambda when signing the string "date: Thu, 05 Jan 2014 21:31:40 GMT" with the private key in that spec
# cwebber lambda: YES
# cwebber it passes!
# cwebber wow what a RELIEF
# lambda nice
# cwebber a couple nights ago I had gotten all the way through the implementation
# cwebber and then I hit the test failures
# cwebber and pretty much collapsed lol
# lambda hehe
# cwebber but then I found out the spec was wrong
# lambda just great...
# lambda oh well, that's what irc is for
# cwebber lambda: let me try signing the other examples and see if you get the same result
# cwebber specifically 3.1.2
# cwebber since that has multiple fields
# cwebber oops
# cwebber not 3.1.2 :P
# lambda C2?
# cwebber yes
# cwebber QpRXM41ULQLVLwOfhZn72EKVloAsBCZ4uQ84KZmpfDDQkOfOuSfAMmrd6GLsPoRiZT0dgZdA9BSSnacYiVREdsEAJ9cftHFDskxaCcqrDBinKD+va9FNZVj1koBm8BzTrOuSFJK+HVO16Du846akXIA7hYK9xa5kAqodEZEB2e4=
# cwebber is what I get here
# lambda what's the string you sign?
# cwebber "(request-target): post /foo\nhost: example.com\ndate: Thu, 05 Jan 2014 21:31:40 GMT"
# cwebber the spec says to do \n rather than \r\n I think for the normalized string
# lambda yes, i get the same for that string
# cwebber lambda: awesome.
# cwebber lambda: I'm going to submit a PR for the spec then.
# cwebber lambda: thanks for testing, and glad I caught your post in the backscroll :)
# lambda but you're missing the param=value&pet=dog in your string
# cwebber wait am I
# cwebber shit
# cwebber lol
# cwebber oops you're right
# lambda with it, the value i get is HUxc9BS3P/kPhSmJo+0pQ4IsCo007vkv6bUm4Qehrx+B1Eo4Mq5/6KylET72ZpMUS80XvjlOPjKz xfeTQj4DiKbAzwJAb4HX3qX6obQTa00/qPDXlMepD2JtTw33yNnm/0xV7fQuvILN/ys+378Ysi08 2+4xBQFwvhNvSoVsGv4=
# lambda but yeah, i guess it's actually rather straightforward
# lambda i was just thrown off by the wrong examples in the spec and stopped trusting my code :)
# cwebber lambda: great
# cwebber I get the same
# cwebber lambda: thanks for catching my error on the query parameters too
# cwebber cool!
# cwebber the only problem I have in my implementation right now then is that I need to call out from guile to python to parse the PEM stuff because I don't have time to get all that parsing working within test suite deadlines D:
# cwebber but that's not the fault of http signatures as much as it is ASN.1 and DER and all that
# cwebber btw I complained a bunch in here that "Rivest's canonical-sexps are so much better for encoding these things" so I decided to do an implementation last night to prove myself right
# cwebber got a working implementation in 3 hours :P
# cwebber stupid PEM/DER/ASN.1