Random Backend Thoughts

[grantcodes]

Ok so just wanted to write down some random thoughts on a backend system while I remember them.

I think we will almost certainly need a (hopefully fairly lightweight) backend system that can talk to microsub endpoints. Functionality I can see being very useful is:

1. Resizing photos - At the moment all photos are retrieved from their original url in full resolution, obviously not ideal
2. Normalising data - It will be a pain to have to deal with a lot of the variables in JF2 data, such as the author property seems like it can either be an object, a url string or completely empty and inferred from the source site hcard. Would be great if it was always an object so the frontend is more consistent. This might be something the microsub spec handles but I don't know. And the same goes for a bunch of other properties.
3. Micropub client - The backend should provide micropub client functionality to post likes, replies etc. I have my micropub-helper node package I can easily use if we have a node backend.
4. Streaming data - Would be great to have some sort of real time updates if possible without needing to refresh.
5. Url to MF2 parsing - For attributes like in-repy-to or children that may just be a url it would be great to be able to expand those into full MF2 objects and pull them into together if we want them.

[cleverdevil]

Good thoughts. A lightweight backend is almost certainly needed, and I think using node is fine, given that the main contributors so far (you, you, and a sprinkling of @EdwardHinkle) are familiar with node. Let's roll with that.

Photo resizing? I'm ambivalent. This to me is way down the priority list, but I do think it would be wise to deal with at some point. I'm much more concerned about getting the UI right and getting Microsub/Micropub implemented.

Data normalization makes sense to me too. Honestly, I find JF2 pretty complex, but the alternative in my mind (JSON Feed) isn't quite sophisticated enough. Normalizing to a simplified subset of JF2 is fine with me.

Agreed on the Micropub client. My biggest request there is that we support syndicate-to. It looks like your micropub library supports syndicate-to, at least from my read.

I agree that streaming data would be useful, but I also don't think its strictly necessary, at least for me, out of the gate. I'd be fine with that being a later optimization.

I'm not entirely clear what you mean by the fifth item? I think you may mean something like "URL unfurling" like is done on Slack and in Facebook. I definitely want this. @mapkyca implemented it for Known, and wrote about it here. There is also some information on the IndieWeb wiki about it.

[jeremycherfas]

Forgive a random drive-by, from an interested person, but if you do implement URL unfurling, please make it optional.

[mapkyca]

Since I wrote the URL unfurling in Known, I thought I'd go in to a little more detail on how it works:

• When a post is displayed, a bit of javascript looks in the content for the first URL.
• This URL is passed to an endpoint, where
• If it's already been seen the unfurled content is returned
• Otherwise the page is retrieved
  • If no error, we extract open graph, twitter, facebook meta tags, OEmbed endpoints, MF2 tags and basic title and description
  • This is then saved.

Rendering, this content is used and a card is generated using the following:

• If OEmbed is present and is whitelisted we use that (you don't want to allow oembed for everything, and also OEmbed is far from standardised in the wild, so you need to do some shimming)
• If no OEmbed, we use open graph
• If no Open Graph, we use title and description

Twitter, Facebook tags and MF2 are not currently used, but are there for future coolness.

Images in Known are also proxied and cached locally for speed and privacy, this proxy also has the ability to transform and resize images. This might be an approach you may want to look at as well, since I found it very useful.

HTH :)

[grantcodes]

Thanks for the feedback everyone :)

So yes I did mean url unfurling and I meant to say unfurling to JF2 data not MF2 (So many similar specs 😅)

@cleverdevil Yeah my micropub library supports every feature of micropub I'm aware of, but the time consuming part if making the UI for it all.

@mapkyca & @jeremycherfas Well in the first case I was only thinking of unfurling internal links - eg I have a gallery of photos with each child as a link to the individual photo pages. So only unfurling content from the people you follow. In the future it would definitely be great to do something like what @mapkyca has done in known.

I think the main issue with unfurling at the moment is there is no pre built way to scrape JF2 data in node yet that I know of. There is a MF2 scraper, but I'm not sure how to do a MF2 to JF2 transformation.

I think in terms of priorities / feasibility for me I will start with login & micropub integration, then the next priority would be microsub - but of course still need some sort of test server for that.

[aaronpk]

This is a great thread, and super helpful as I'm building out my Microsub endpoint. The goal of the Microsub server is to handle a lot of these challenges so that clients like this don't have to worry about nearly as many moving parts.

• Resizing photos - I think it would be a completely reasonable thing for the Microsub server to handle this. However, I'm not sure how best to handle deciding what size to resize things to, since different clients may have different requirements on acceptable image sizes. Any thoughts?

• Normalising data - This is the primary goal of Microsub, to take Microformats/Atom/RSS/JSONFeed documents and convert them all to a simpler format for consumption by clients. I've been working on this for a long time as part of XRay. The idea is there will be very few options for how posts are returned, and should be easy as possible to consume. This is intended to be captured in the JF2 spec, although that is a bit out of date compared to how I've implemented it in XRay already.

• Streaming data - I agree this would be great, but will likely not be supported by every Microsub server even if some do support it. Obviously you'll want to have a fallback for servers that don't support it, but I would like to have a streaming API as part of the spec. I've had good luck with the EventSource API both on the client side and server side, so how would you feel about using that as the baseline? I can write up a draft of how I'd expect that to work.

• Url to MF2 parsing - I would expect the Microsub server to take care of all of this, so the client wouldn't need to worry about it. It is definitely possible that a server may not expand a URL though, so the client should be prepared to render an in-reply-to that is just a URL and not a full post.

[martymcguire]

Regarding resizing photos, a model like imageproxy might be nice. Transformations like sizing, cropping, and rotating are specified in the URL, which is signed with a shared secret to avoid abuse.

[aaronpk]

Right, but which part in the flow is responsible for that? I think ultimately the client needs to decide what size of image to request. Should the client be responsible for using an image proxy service? Or should the Microsub spec define a way to handle that?

[martymcguire]

I lean towards putting that responsibility on the client, possibly pointing client implementors at some existing implementations to lean on since I don't know that a resizing image proxy standard exists.

[grantcodes]

Closing this, as everything is now handled, or better being discussed elsewhere