snarfed
Bluesky: publishing
We only have backfeed for bsky currently - will use this issue to track publishing work.
Trying to work out how to actually turn this on. Setting CAN_PUBLISH = True and adding Bluesky to the list of sources in publish.py doesn't seem to be enough. I think it's something to do with adding 'publish' to the source's features field but I'm not sure when to do that when Bluesky doesn't actually use auth scopes at all. Do you think it's OK to just add this feature to the source at initial login, and if so, where's the best place to do that? Is it in bridgy or in oauth-dropins?
Yes! publish in features is it. And good question re scopes. I guess we could make it a Bridgy-internal toggle that users can opt into, but I'm also fine with always enabling it, at least for now. I think you'd just hard code feature here to 'listen,publish':
https://github.com/snarfed/bridgy/blob/87038d39157476a526a6bd7ce9f566679dd1fb08/bluesky.py#L73
More:
https://github.com/snarfed/bridgy/blob/87038d39157476a526a6bd7ce9f566679dd1fb08/models.py#L525-L535
Btw backfeed seems pretty stable, congrats again! I'm ready to announce it if you are. Want to do the honors?
Great, thanks, I'll have a go at this :)
Btw backfeed seems pretty stable, congrats again! I'm ready to announce it if you are. Want to do the honors?
Sure! Will write that soon- prob not today as I'm a bit under the weather but in the next few days for sure
Found some energy from somewhere! Hope this is OK. https://www.joelotter.com/posts/2023/10/bridgy-bluesky/
Random note: Bluesky still doesn't have proper embed support, and bsky.link appears to be dead, so I'm skipping post embeds in reply previews.
Bluesky has link cards (previews0, which unlike on other networks are optional and it's up to the user which link in a post becomes the link card. I propose that to start with we just handle the last link in a post as the card, as that feels like the most common usage. Later, we might want it to be adjustable using some specific bridgy property. What do you think?
Though interestingly Mastodon does actually choose the first link. I still think last is the more desired behaviour...
Last link sounds good! Or even skip embeds altogether to start. I'm all for starting with the simplest thing that works end to end, then expanding.
Think I've got preview pretty much working for the basic feature set. I'm a bit confused how to actually do stuff against Bluesky though. Do I need to write raw ATproto repo-write queries? Does lexrpc include a way to do this? Had a look at how bridgy-fed does it and it seems very low-level!
Hah, yes! I think you just call com.atproto.repo.createRecord. It's a little hidden because it's in the com.atproto lexicons, not app.bsky. https://atproto.com/blog/create-post
Hmm I'm not sure what I need to add in terms of the endpoint handling for e.g. /bluesky/publish/start, it seems very tied to the OAuth dropins in a way that I find a bit confusing given Bluesky's OAuth is fake. Any advice?
That is totally true. 😕 I had the same problem when I added delete for Bluesky a bit ago, maybe follow the way that works?
So I'm still mildly baffled by the flow here but I think what I'm missing is functionality for the OAuth Dropins Bluesky Callback's dispatch_request function to be able to read state out of the request, and use the source ID in that to retrieve an existing user auth, if it exists. Does that sound correct? Is that actually safe to do?
Sounds right, but you can probably get much of it for free, let me come back when I have a bit more time to sketch something. Btw feel free to skip interactive publish/preview entirely for now if you want, I'm happy to ship just webmention-based publish, and then add on interactive afterward!
Sorry the auth stuff is so difficult btw! Obviously the non-OAuth part here is awkward, but also the auth code on the Bridgy side in general is probably over-abstracted.
Random discovery is that Bluesky (presumably intentionally given a repo is supposed to be user-owned?) does not validate dates. We can publish posts at the time the source was written. https://bsky.app/profile/joelotter.com/post/3kefvqwq6g424
Awesome! Congrats!
And yeah people like @DavidBuchanan314 have been all over that. The team says indexedAt is the more-trusted timestamp since it's from the relay/appview. Still, amusing!
Am I right in thinking lexrpc doesn't currently support non-JSON request bodies?
Alright, I've got it uploading images!
The next thing is facets for links and mentions. I can see that from_as1 actually has this, but it a) only does facet logic when the HTML content is identical to the text, which I don't see ever being true and b) appears to expect links and mentions to be present as tags on the AS1 object, which I don't think we currently do in vanilla bridgy?
So cool! Congrats! And yeah good point, lexrpc supports binary output and input (less well tested) server side, but not client side, sorry about that. Did you have to add it? (Thank you if so!)
Re facets, afaik we've never actually used the AS1 => Bluesky facet code for anything real yet, so yeah I can believe it's untested (at least in real situations) and likely broken in some ways.
For HTML content though, yes, that's intentional, I probably should have added a comment. I did the conversion from AS1 tags since it was easy, but for HTML, I didn't want to try yet since it seemed harder, and I didn't have a use case yet. I guess we do now!
We figured out lots of these details for publishing to Twitter, hopefully those decisions work here too. Eg we parse out mf2 and use it for explicit structural elements like media, and otherwise just run source.html_to_text and use its output as is. For Bluesky facets specifically, I don't actually think we have any precedent in Bridgy publish for @-mentions or links. I guess we could try! I'd be inclined to think about it after we ship a first version with just plain text though.
(Fwiw we do end up with AS1-style tags with indices in granary/Bridgy when we convert from some silos, eg tweets from Twitter with mentions, links, etc. Doesn't really matter here though!)
I ended up just implementing upload with requests directly - I find lexrpc quite hard to reason about internally due to the codegen stuff so I might not be the best person to try and add a whole additional class of input data!
RE facets, that makes sense. I think the linkify stuff we use for preview might be of some help here, though there will assuredly be some weird nuance due to unicode shenanigans.
Are we able to ship the micropub stuff without showing any publishing UI? If so that might work well, otherwise I'd worry about users seeing a broken-ish feature.
Are we able to ship the micropub stuff without showing any publishing UI? If so that might work well, otherwise I'd worry about users seeing a broken-ish feature.
Good point! I guess I more meant merge than ship, ie we could merge this with just webmention support first, to keep the PR(s) manageable. We can definitely ship that first too, but yeah we'd want to hide the interactive form part of the publish UI if we do.
Apologies @snarfed, need to focus on some non-Bridgy stuff for a bit that I've been neglecting! I've put my WIP in the bsky-publish branch on my fork of Granary, which is where basically all of the work is: https://github.com/JoelOtter/granary/tree/bsky-publish
I mean to come back to this in two or three weeks but if you'd like to race ahead please don't hold back on my account!
No worries! Totally ok, no obligation. I probably won't work on it much myself in the meantime, but I'll keep you posted. Best if luck with the rest!
@JoelOtter just FYI I'm starting to look at this again. Let me know if you have any time freed up and you're interested in working on it with me!
Hello! I'm still a bit swamped - we're bringing our game out of Early Access at the end of February so I have a few things pulling my attention until then. From March on I'll have a lot more time to get back to this, but if you want to go ahead please do! Happy to help out with reviewing code in the interim.