btremI have a small static website for a family member that is currently on a shared hosting service, along with email. The family member in question is unhappy with the email service, and wants to move. I'm strongly inclined to move email and web to separate services. For the web, either Amazon Web Services or Netlify.
btremI have some experience with AWS, and find it to be tedious to set up and update. Is Netlify any better? I was on the faq/quick setup page and it seems pretty straightforward setting it up and connecting to GitHub, which would be easy since her site is already in a GH repo. Thoughts?
gerben, [Jo] and [jeremycherfas] joined the channel
[KevinMarks]Is github pages not usable? I found Netlify pretty easy to run a static site which is node+express and everything in a statically served directory.
meroleIm trying to build a web app with svelte and sveltekit. Need a good db backend, currently im using pocketbase, will it be safe to use it in production? Any1 with any experience?
[Murray]@btrem is a long-time Netlify user 👋 it's certainly extremely easy to set up and use, UX is one of its strong points. Also free for small sites (can't remember what AWS is like). I'd strongly recommend it as a service 🙂 There are also competitors (with varying feature overlap) like Vercel and Cloud Cannon if there's anything you dislike about Netlify specifically
jonnybarnes, Xe, gerben and btrem1 joined the channel
[KevinMarks]I was using Heroku for my static node site, and when their github integration broke I switched to netlify in about 30 minutes, it is handy.
[tantek]aaronpk, I know Micropub has extensions for POSSE destinations, is there a way to extend that to federation destinations? e.g. posting via Micropub and automatically having it trigger Bridgy Fed?
[schmarty]from my perspective, because syndication targets are specified in the micropub standard both in terms of what is available, and `mp-syndicate-to`, i lean towards having the micropub clients be "in charge" of this.
aaronpkone way to flip this around is to make the micropub client smarter, where the micropub client can pre-fetch the post for reply context (which is also good UX!), at which point it can check the syndication boxes for activitypub if it knows which of those in the syndication options is the right one to check
[tantek]and obv all self-replies, per prev chat with [snarfed] and I think he filed a Bridgy Fed issue on it (self-replies should go to all the same destinations as the thing they are replying to, transitively upthread)
[schmarty]i agree that cluttering up the UI with syndication options all the time doesn't feel right. but if the client wants to try and figure out ahead of time, sure! i'd even take an option that i configure per-channel in monocle.
[tantek]I believe the server should be responsible for answering the "can this" question, in the protocol, and then the client can answer (potentially with UI) the "should this" question
aaronpkand am I correct that you are saying it would be too burdensome to add some code in your micropub server that fetches the in-reply-to URL to determine whether it's an activitypub post?
[schmarty]with my current architecture it would be awkward. my micropub endpoint saves what it gets and kicks off a build. the first time my site learns anything about a given URL is when i fetch reply context data (i just run it through xray)
[schmarty]the publishing step isn't currently allowed to rewrite things about posts, just add extra information, so i'd need to do that and update my templates to look in that new place.
aaronpkthinking how i'd do this with monocle, i guess this is actually more of the job of the microsub server. the microsub server should know whether a post is an activitypub post and then it can tell the microsub client that information so that it can check the syndication box
aaronpkso the question for others is whether you think this is a good and sustainable pattern, moving more of the reply context logic into the micropub clients
aaronpkfor example what are the implications for doing this from an iOS app, if you reply to something in the iOS app, the app needs to know whether that thing is an activitypub post, so it would have to have a way to fetch the post too
[schmarty]having any of these parts know whether a post "is activitypub" is interesting. i don't think quill's reply interface link preview currently checks to see if a page supports webmentions?
[snarfed]this is how I've replied/liked/reposted to the fediverse via BF for a long time. the WordPress Syndication Links plugin (hi GWG) supports BF as a synd target
[schmarty]is there a standard way of detecting whether a post "is activitypub"? i've seen discussions come through here that made it seem tricky conneg--
[snarfed]unrelated, the SWICG call got me thinking about ActivityPub auth. it seems like the main point of AP's S2S auth right now is authenticating the server sending an HTTP request to the one receiving it
sknebel[snarfed]: i.e. between your cluster nodes in your DC, sure, why not. in random software you want random people to be able to write and deploy compatible versions... it's going to be messy
aaronpk(i *think* the would be roughly equivalent but there are many reasons why mTLS is not a viable option, so much so that there's been years-long efforts to replace mTLS in the OAuth world with something else)
[tantek]can we go back to enhancing Micropub (whether by protocol, extension, convention) to handle server indication of "this post can federate to AP/BF etc.", client detection of that, client optional offering UI to opt-in for such federation (like syndication), then client indication to the server that "this post should federate to AP/BF etc." and letting the server handle it?
sknebel[snarfed]: for one thing, afaik AP implementations do per-user keys. so now you either run *your own* CAs or you are trusting on free CAs being very accomodating to you requesting thousands of certs
[snarfed]sknebel yeah I knew that would come up. yes, but those are all _custodial_ keys. fediverse servers all generate, store, and manage them. so in practice right now there isn't a meaningful difference btw per-user and per-server keys
Loqi🗺🐉 Here be dragons is in general a warning of potential dangers or dangerous areas, originally on physical maps, on the IndieWeb it refers to particularly problematic silos that usually formed in response to entire sets of abusive behaviors and accounts being banned from Twitter https://indieweb.org/dragons
[schmarty](staying on topiccccc-) especially for things like syndication rules i tend to shy away from pushing logic "into my site". when i have to have a branching internal model of what it will "do for me" when i publish something, i tend to trust it less and therefore use it less.
GWGSyndication Links for WordPress was deliberately meant to be a pluggable system...so the syndication selection code doesn't know what happens when it hands over to each provider. In most cases, Bridgy.
[schmarty]are there any video demos or screenshots of how syndication links for WP works as a user? i don't have a WP site handy to set this up on to try out the user experience 😅
LoqiThe NASCAR problem is when there is a jumble of branding icons in a user interface, like 3rd party proprietary sign-in/login options (instead of IndieAuth) or silo-specific sharing buttons (instead of web actions) on websites, that is visually busy and often noisy, distracting, and overwhelming https://indieweb.org/nascar
Loqiapp is a top level domain that requires HTTPS and was opened to limited registration on 2018-05-01, with availability to the general public on 2018-05-08 https://indieweb.org/.app
[aciccarello]On the content section of the survey there's a question about what you've used to make HTML machine readable. Lists <time>, <data>, microdata, microformats, RDFa, and JSON-LD
[KevinMarks]on the can vs should point about syndication - does the micropub response indicate the default state of the syndicate checkbox to the client? Or is that too subtle?
[tantek]On page 3 of the survey "Content", there's a question on: "Which of the following have you used to include machine-readable data in HTML?" with [x] checkbox items for: <time>, <data>, Microdata, Microformats, RDFa, JSON-LD — this would make sense for every dev here to answer
[tantek]On page 7 of the survey "Other Tools & Features", there's both a question on "Which of these static or dynamic site generators do you regularly use?" with [x] checkbox items for: Astro, Eleventy, Gatsby, Hugo, Jekyll, Next.js, Nuxt, Other… — and you can choose "Other..." and enter your own software
btremI was curious about your url scheme for images that are connected to a post. I have a scheme for my site. Took me while to arrive at it. It works, but I'm curious about other schemes that might be better than mine.
[schmarty]my image server is all content-addressed which is great for deduplication but is a ridiculous bucket of undifferentiated files without external data (like my site's HTML)
aaronpkbtrem: my images in posts are stored in a folder next to the post, so the URLs are all under the post URL. This media subdomain is more like ephemeral storage and my site will go copy images from there to the actual storage when I make a post
btremaaronpk: That scheme would be logical, but I think a bit hard to backup. I have my raw images (before resizing/converting) all in one directory that I can easily backup. Outside of the posts, which are in a git repo.
btremI just starting taking the survey. (I logged into #dev after it was posted, hence my confusion about the image.) So far, there are more things I've never heard of than things I have. Like what is <selectlist>? Is it a <select> element that is more easily styled? That'd be an odd thing to introduce to html.
btremaaronpk: I don't back up the posts. Those are in a git repo, which is backed up to github. So it's only the images (and other media) that I need to backup.
btremAh, I was warned not to put digital files in a git repo, so I set it up without them. I've since read posts arguing that it's fine to include e.g. images in a repo. But I was already down a different path.
aaronpkMy theory is if it's ok to serve on the web it's ok to put in git. I'm not going to commit a 2gb video file to the git repo but I'm also not going to put that file in a video tag
LoqiGit Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server https://indieweb.org/git_lfs
aaronpkI think the warning is more important if you have a lot of frequently changing large files. Cause then you have to pull down all the old versions in a clone. But if you're basically only ever adding files then there's less redundancy
btremaaronpk: yeah, that's what I learned after the fact. Having them in the repo would make the site more atomic and portable. But as I said, I was already down a path when I read the countervailing point re: digital files in a repo.
[schmarty]i had weird experiences with git LFS. even now that it's more well supported by git hosts and git client versions. it requires extra setup when creating and cloning repos, for example. ultimately i learned that under the hood Git LFS works a lot like a content-addressable remote filesystem, and that i could use a micropub media server in the same way, so i just skipped to the end. :}
btremNot taking advantage of Loqi. Just curious what prompts her to interject. Like above, she said "+1" and I had no idea why until someone explained it.
btremre: the survey. I'm on the "which methods have you used to manipulate the DOM?" I checked jquery, but I can't decide if I should check "negative experience." I doubt I'll ever use jquery again, because the things I need can be done in plain js. But for the brief period that I used it, it wasn't negative.
[KevinMarks]https://dev.to/tigt/why-not-react-2f8l is very interesting, especially the bit that starts “Code struggles to escape why it was created. *You can often trace the latest version’s strengths and weaknesses all the way back to the goals of the original authors”*
AramZSI will note that there was a seriously long period where jQuery was famously disliked in a bunch of dev circles. People wrote pages and pages about how terrible it was.
btremI didn't check "negative" for jquery. I only *thought* about it because I don't think I'll ever use it again, but that's because, as [KevinMarks] said, it got written into javascript. So I no longer need it.
btremAnd am surprised at the sheer number of features that I've never heard of. But then, my paying job is server/bartender, not web dev. So there's that.
btrem[KevinMarks]: I read that post yesterday. Seems like the author knows what he's talking about, but I've never used React, so it's hard for me to tell. (Never used Vue either, nor next.js, nor....)
[KevinMarks]they have this thing where they flush placeholders and js that copies them up, but with grid your document order is independent of your display order, so you don't need to do that.
geoffo, [Niklas_Siefke] and gerben joined the channel