social.tchncs.de is one of the many independent Mastodon servers you can use to participate in the fediverse.
A friendly server from Germany – which tends to attract techy people, but welcomes everybody. This is one of the oldest Mastodon instances.

Administered by:

Server stats:

3.7K
active users

#indiewebcamp

0 posts0 participants0 posts today

To celebrate IndieWebCamp: San Diego 2024 I want to send you a sticker.

I got these stickers printed after @nsmsn got these commissioned from a discussion we had at a past Homebrew Website Club.

If you want one of these, you can email me your mailing address and I'll ship one out to you. I'll try to send these anywhere in the world USPS will let me but if for any reason that's not possible, I'll let your know.

(bnj.pw/t5_Q1)

New blog post: “Updated Scroll Markers in the Table of Contents”

blog.kizu.dev/toc-scroll-marke

I’ve spent most of the day inside the delayed and cancelled trains (thanks, Deutsche Bahn). I did not have an opportunity to come up with a good post for today, but both yesterday (and a bit today) I hacked on my blog, as a part of the #IndieWebCamp.

I did the thing I wanted to do during this weekend: update my blog’s Table of Contents to be similar to what I have on my main site.

✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web. The consumer Infinite Scroll Web leaves us feeling empty. Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia. A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks) live-tooting of the demos^1, I noticed a few errors, typos or miscaptures, and pointed them out in-person. Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat. We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment. 13 years ago I wrote^2: “The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.” Now I want the Read Write Suggest-Edit Accept-Edit Update Web. The ↪ Reply button is fairly ubiquitous in modern post user in tantek.com/2024/245/t1/read-wr

tantek.com✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web. The consumer Infinite Scroll Web leaves us feeling empty. Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia. A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos^1, I noticed a few errors, typos or miscaptures, and pointed them out in-person. Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat. We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment. 13 years ago I wrote^2: “The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.” Now I want the Read Write Suggest-Edit Accept-Edit Update Web. The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs). Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits. If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit. Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots? To enable such UIs and interactions across servers and implementations, we may need a new type of response^3, perhaps with a special property (or more) to convey the edits being suggested. There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki: * https://indieweb.org/edit Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem. For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons: ✏️ Suggest Edit and link it to an edit URL for the static file for the post. I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects: https://tantek.com/github/cassis/edit/main/README.md This will start the process of creating a “pull request”, GitHub’s jargon^4 for a “suggested edit”. After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit. It’s an awkward interaction^5, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions. We can start with the shortest path to getting something working, then learn, iterate, improve, repeat. #readWriteWeb #editableWeb #suggestEdit #acceptEdit References: ^1 https://indieweb.social/@kevinmarks/113025295600067213 ^2 https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11 ^3 https://indieweb.org/responses ^4 The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/ ^5 “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies. This is post 20 of #100PostsOfIndieWeb. #100Posts ← https://tantek.com/2024/242/t1/indiewebcamp-portland → https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed - Tantek


https://shkspr.mobi/blog/2024/05/49911/

While attending IndieWebCamp in Brighton a few weeks ago, a bunch of us were talking about blogging. What is post? What should it contain? What's optional?

Someone (probably Jeremy Keith said:

A blog post doesn't need a title.

In a literal sense, he was wrong. The HTML specification makes it clear that the <title> element is mandatory. All documents have title.

But, in a practical sense, he was right. This blog post has an empty <h1> element - the document might be semantically invalid, it might reduce accessibility, but the post is still available.

A blog post can be a plain text document uploaded to a server. It can be an image hosted on a social network. It can be a voice note shared with your friends.

Title, dates, comments, links, and text are all optional.

No one is policing this.

Go create something which doesn't fit properly with the rest of the world.

https://shkspr.mobi/blog/2024/05/49911/