Becoming a "citizen of the IndieWeb"† seems to require you to be a web developer. Level 1 requires knowledge of HTML, or a CMS that exposes the rel attribute on links (is that common?). Level 2 requires specific CSS classes and... more than I can summarize succinctly here. And there's still Level 3 to go. It's hard to see this growing beyond web developers unless it's baked into other software as an incidental.
† https://indiewebify.me - linked in the article as "a quick start to becoming a citizen of the IndieWeb"
Those don't really steer it out of web developer territory though, do they? Known's an SSG, and unless WordPress has grown a lot I doubt it's a complete solution (not theme dependant, etc).
That meta chat room is something. Is that how you came to this thread? It's strange to see dismissive comments in there but no outreach to the sources of them. Feels very cliquey.
Is SSG a static site generator? I'm pretty sure Known is a SQL database backed dynamic kind of thing. I looked at it several years ago and I don't remember it being static.
> unless WordPress has grown a lot I doubt it's a complete solution (not theme dependant, etc)
I know very little about WordPress. I do know there are IndieWeb plugins for it. To what extent WordPress might be a solution for you, I wouldn't have any idea.
> That meta chat room is something. Is that how you came to this thread?
I wasn't in the chat room. IndieWeb is something that I've had some interest in and I generally look at posts here about IndieWeb related stuff when they show up from time to time.
> Is SSG a static site generator? I'm pretty sure Known is a SQL database backed dynamic kind of thing. I looked at it several years ago and I don't remember it being static.
You're right, I glanced over it too quickly. Installing it is still too much for anyone without basic web development or system administration skills.
> I know very little about WordPress. I do know there are IndieWeb plugins for it. To what extent WordPress might be usable for you, I wouldn't have any idea.
From the chat log it's my understanding that the theme handles markup as opposed to plugins. So it seems unlikely that you could rely on plugins alone to get full functionality.
It's probably as simple as it gets given the set of constraints (I assume) you've set on yourself. To open it up to a wider audience you'd either have to have write some sort of provisioning tool (possibly a local app) or lean on someone else's (Linode marketplace, etc). DNS shouldn't be overlooked either as something troublesome for users.
you would add a provisioning tool to get rid of download + upload?
Hm. I consider that crucial for a user's control (agency) over it's digital property. To not depend on my tool for the existencial moments of creation and deletion of what is in between populated by my (other) tool.
I don't see the distinction you're drawing. The ability for a user to get their data in and out of a system is crucial to a user's agency, as is the ability to provision and tear down a service at a name they control. UNIX system administration skills aren't a prerequisite for either of those things. That they are largely necessary today is a failing not a feature.
> I refer to remote copying and ensuring proper permissions of a single file. And deleting in case. How more basic could it possibly be?
Loads! There's a lot of work to do here, maybe it's not work you're interested in - that's ok - but there is definitely work to do. Are you familiar with things like Yunohost, Sandstorm, and the like? This is a nascent field, in app terms it's barely at untar-configure-make-install relative to an app-store one tap install.
> The permissions may be embarrassing and peculiar for Microsofters, but adding other tooling doesn't simplify.
I've had the experience of running a hosting control panel used by a couple of thousand users (organisations) and I can absolutely tell you that tooling does simplify things for users. It doesn't even have to be that good, every incremental step we made got more users using more things. Things they easily could have done themselves (they had SSH, Postgres, MySQL, Perl, PHP, etc).
I'm not worried about folks not learning UNIX system admin skills. I am worried that one of the proprietary service stacks (in which I include local ones like Synology's App Center) will become a defacto platform in the same way proprietary OSes have won on the desktop and mobile. Fortunately they're not much good at the minute, but it's a blue ocean for them if they get better first.
And to be clear, I'm not advocating that users should not have to learn anything. I don't know where the bar will end up, but I think it'll be far away from chmod, one way or another.
They add dependencies, complexity and TOS to the stack. That's not appealing, even less so when it just promises to hide cp+chmod.
> UNIX system admin skills
You talk about a single copy + chmod like being rocket surgery. I know that FUD. It helps selling administration tools and services and keeping people dependant. But I am all about enabling individual agency.
So in the end operating anything requires care or call it administration. This complexity can be hidden (comes with additional otherwise unnecessary dependencies and lock in) or reduced (my admitted radical approach).
So I both lower the bar and educate that cp+chmod don't hurt. The hardest part is prbly downloading and using a ftp client.
I'm going to have one last go. Low friction network services are inevitable. There will be point and click, or since it's 2021, tap, interfaces for allocating resources (compute, DNS, storage, etc) to services. The technology stack that makes that happen can be composed of open standards, protocols, and software, or it can be a proprietary gated one. Either way it'll probably be built on UNIX, it's just a question of whether we'll get a seat at the table, or if it'll be UNIX in the iPhone sense.
We have very different ideas as to what complexity is required versus necessary, and we also likely have very different ideas as to what the competitive landscape for a product like yours is.
I do empathise with what you're saying, but there is nothing radical in your approach. It's a staid and common position in technical circles, and in my experience it lends itself to being blind sided.
Hopefully you will prove me wrong but I think I'll be proven right.
I'll do my best to offer a low-fat, no-sugar option to get stuff into the internet, that's absolutely layperson-friendly. And contribute to the fediverse if wanted. And even the silos.
Very few steps, no unexplained jargon, very few core concepts. Ideally no running code facing other users (alas, the search). Use existing tools, no NIH. Align with what the hosters explain and sell.
But absolutely zero dependencies that might need patches (except a webserver). No node, PHP etc. No DB. A minimal trusted computing base. You can simply copy the whole site to backup/mirror it.
Last weekend I decided to remove all third party services/javascript from my website, replacing them with external links (for the share button or the contact form), nothing (for google analytics[1]) or with web mentions (for disqus).
Not sure how viable it is since it was actually more work than I thought it'd be, but at least I feel better now about my site not loading external stuff and setting unnecessary cookies. Now I guess I should actually write more stuff to see if I get mentions (and to test how vulnerable to spam it is, I suppose). I haven't ruled out looking into other ways to implement federated comment systems—or similar, like web mentions—though[2].
[1]: That said, I'm using cloudflare so I guess I do get its analytics.
> remove all third party services/javascript from my website
Congratulations on that! I personally believe it should be the foundation for any website, but well...
> how vulnerable to spam it is, I suppose
This depends on how you implement it. You may implement simple rate-limiting/quotas, manual verification, or go the fancy way and implement signatures and/or vetting (not widely implemented yet in the ecosystem).
> I'm using cloudflare
Please consider not doing that. It's even worse than having 3rd party JS on your website. At least with 3rd party JS, i can disable JS in my browser or use an adblocker. When you use Cloudflare, you ask a private company to strip & search every person who'd like to access your website, and many persons are stuck in the process.
Cloudflare does have an option to let users from Tor access your website. But if you don't tick it, the default setting will leave all privacy-sensitive people at your doorstep, with a bad experience of your site. If JS is enabled, the CAPTCHA will loop forever driving us insane. If JS is disabled, the CAPTCHA won't even load.
Cloudflare is one of the worst things that can happen to Internet freedom, by centralizing all communications (especially as part of a free tier that encourages many non-profits to move over) and terminating TLS connections on there. If you enjoy free-software, privacy and computing ethics, please never use any Cloudflare product or equivalent. If you have problems with DDOS, many hosting providers have very good solutions that do not infringe on your or your readers' privacy.
Could someone explain what the difference between a webmentipn and the ancient pingback/trackback concept is? It seems just a difference in presentation?
If you implement webmention spec then the URL and page that mention you have to have a link on the page back to the post they are mentioning. This filters out a lot of spam. There's a more complicated anti-spam system that isn't fully implemented yet.
I personally run a catch-all for POSTs on my webmention endpoint so I can do pingback and arbitrary stuff with it too. In terms of spam, yeah, old trackback/pingback spammers are still doing their thing. I get a dozen or so a day. It's easy to filter most out by looking for any triplicate or greater POSTs but that requires doing batch processing.
Overall I think webmention would fall to spam if it became popular but right now it's a wonderful time. This applies to all systems open enough to be useful. It's the natural lifecycle.
I like the idea of aggregating mentions from around the web on my personal static site. Ideally I would want to always have the most recent data, and not expose my site in a way that could be hacked.
These are the implementations that come to mind:
- re-render entire site on receipt of new mention (live data, but dangerous)
- re-render site on a schedule (less dangerous, nearly live data)
- fetch mentions client-side (live data, safe, but requires javascript enabled in the browser)
[UPDATED] - use cloud edge worker to insert the live data as the page is being returned to client (live data, safe, works with JS disabled in browser)
> not expose my site in a way that could be hacked
What do you mean? XSS? SQL injection? What are you afraid would get hacked?
> use cloud edge worker
So you let a 3rd party private company interfere in serving your website? Of course we rely on third parties for some things, but that's a pretty dramatic course of action to let one of those edit your webpages on the fly.
> What do you mean? XSS? SQL injection? What are you afraid would get hacked?
Perhaps hacked isn’t the right way to describe it. The issue is that if you setup a re-build if your static site on receipt of a mention, that means anyone on the internet can rebuild your site whenever just by creating a mention. That has the potential to take your site down because for example you might run out of build monthly minutes. There are probably other ways such a setup could be used to cause issues.
> that's a pretty dramatic course of action to let one of those edit your webpages on the fly
The way I have been thinking of cloud edge workers is just another place you can run some compute when you get a request. I think I can see why you might be hesitant, so you might have a valid point, I haven’t spent a huge amount of time analysing the threat vectors that are inherent with edge workers.
In your opinion, why are edge workers more dangerous than the usual hosting provider that ‘interferes’ with the request by rendering and returning the page?
Live-but-throttled is a decent compromise between the first two. Maybe something that submits a notification directly to you, as chance to approve/deny/respond, moderate what gets published, and be generally aware of what you’re publishing for that matter.
- use edge workers to fetch and insert data as the page is being returned to the client
That would work in browsers with JS disabled.
You could also have client-side code to update with live data as it comes in.
The downside is that it’s not very portable code, but that’s the same for most serverless stuff, and it’s probably not that difficult to re-implement on another platform.
Oh yeah I hadn’t considered the need for a review & approve step. That’s pretty important. So actually implementing web mentions is kind of non-trivial.
This page describes receiving WebMentions. If you're looking at sending them, a while back I implemented that in a small npm library as part of a grant. In case it's useful to anyone: https://www.npmjs.com/package/webmen
In case people are wondering, it's as simple as parsing your own HTML pages for links, fetching those links, parsing the remote HTML for a webmention endpoint, and if this exists, send a request over to it with headers indicating the URL of your own page, and the URL you linked to.
The nature of the interaction is not contained within the webmention, but rather the site on the other site will fetch and parse your page to figure that out. That information is within the HTML itself, such as `<a class="u-in-reply-to" href="foo.bar/baz">Commenting on this article</a>` to express a commenting/reply relationship.
This is cool! I'll be looking into adding webmentions to Kalaksi.com my rss-based social network. It makes perfect sense and is very much aligned with the "open web" I'm trying to help survive.
Kalaksi is really cool, too bad it didn't catch up! I applaud your goal to make the open web thrive by using RSS. I see that you're even incorporating RSS-bridge, that's very cool !
Since you want to use the open web standards, you probably have heard of the indieweb movement. They have been working in this field, have standardized a bunch of protocols, among which webmention is only one (see https://indieweb.org/graphics#Illustrations_and_Sketch_Notes) and are all about doing first. I think there's a lot more you can reuse from their work! Kalaksi could be a nice demonstration of what the openness could bring. In particular it seems Kalaksi could become a social reader (https://indieweb.org/social_reader). This is exactly what we need to remove the importance that siloed private social networks.
Small comment: it seems the planets don't have the <link rel="alternate"> in the header that allows the browser to detect the rss feed, so one can't use the page directly but has to copy-paste the link to be able to subscribe outside of Kalaksi
Hubzilla is different. Kalaksi is still centralized, but the content is fully open and readable from anywhere (via RSS). So you can publish/curate, and your readers dont necessarily need to use kalaksi to access it.
Oh, that's really sad. If i may, why would you consider developing software that's not free software? Also, why would you develop software to provide services for other users, that they can't selfhost if/when you're not longer hosting the service? That sounds like serious footguns/antipatterns to me, so i'm curious what's your rationale :)
Basically I'm not clear where to go with it (if I go anywhere :p), and perhaps offer paid accounts with more features (like hosting images, videos, etc). And yes, I know this is not mutually exclusive but I dont see the point of everyone installing their own kalaksi. Its not made as something you self host for your own content but as a central platform.
If I ever abandon the project, for sure the code will go open, if not before :)
Yes when we were standardizing Webmentions we all knew that. Personally, because I got started coding in 2005 around the time they became popular for blogs (https://www.hixie.ch/specs/pingback/pingback), but 'pingback' isn't always well defined (by one nonprofit org's IP), it involves XML-RPC (while form-urlencoded works fine and is simpler for limited scope), and the W3C Social WG charter read as somewhat instructive to prefer JSON or form-urlencoded encodings to XML. https://www.w3.org/2013/socialweb/social-wg-charter
> I guess it doesn’t allow comments unless you mention it from your site?
That is the principle yes. However with or without webmention, you can build a public commenting system on your website. All it takes is form-processing on a server-side endpoint (to receive comments and filter out spam) and retrieving/formatting comments either on the server site (querying the endpoint whether per-request for dynamic sites, or as part of your build pipeline for static sites).
Webmention is a technology that enables websites to federate using semantic HTML. Comments are an order of magnitude simpler and never ever required any JavaScript or third party service. I never understood why people use Disqus, and i certainly will never enable JavaScript to comment on a website.
I think it's a reasonable approach to consider spam as an authorization issue, and authorization was left to extensions, but generally it could involve oauth2/oidc + dynamic client registration + any policy of allowlisting webmention senders
* Webmentions are like pingbacks, but use a simple POST instead of an XMLRPC call;
* They're not particularly new (2013ish);
* Webmention.io is a service to make it easier to participate in webmentions without operating your own POST endpoint.