Extending the Interaction Between AI Agents and Editors
We explore the interaction of AI agents and editors by mixing tool definitions with prompts using a simple Markdown-based canvas. ⌘ Read more

@eapl.me@eapl.me here are my replies (somewhat similar to Lyse’s and James’)

1. Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax ![NSFW](url.to/image.jpg) if something is NSFW

2. IDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.

3. Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.

4. Discovery: User-agent for discovery can become better. I’m working on a wrapper script in PHP, so you don’t need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that’s the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.

5. Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs

6. Languages: If the need is big then make a separate feed. I don’t mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it’s about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.

7. Emojis: I’m not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?

**(#gctrz4q) @falsifian Only that this rendering behavior comes from yarnd’s Markdown parser library that is used:

What has text/markdown go …**
@falsifian @www.falsifian.org Only that this rendering behavior comes from yarnd’s Markdown parser library that is used:

What has text/markdown got to do with this? I don’t think Markdown says anything about replacing ¼ with ¼, or other similar transformations. It’s not needed, because ¼ is already a … ⌘ Read more

@bender@twtxt.net @prologic@twtxt.net I’m not exactly asking yarnd to change. If you are okay with the way it displayed my twts, then by all means, leave it as is. I hope you won’t mind if I continue to write things like 1/4 to mean “first out of four”.

What has text/markdown got to do with this? I don’t think Markdown says anything about replacing 1/4 with ¼, or other similar transformations. It’s not needed, because ¼ is already a unicode character that can simply be directly inserted into the text file.

What’s wrong with my original suggestion of doing the transformation before the text hits the twtxt.txt file? @prologic@twtxt.net, I think it would achieve what you are trying to achieve with this content-type thing: if someone writes 1/4 on a yarnd instance or any other client that wants to do this, it would get transformed, and other clients simply wouldn’t do the transformation. Every client that supports displaying unicode characters, including Jenny, would then display ¼ as ¼.

Alternatively, if you prefer yarnd to pretty-print all twts nicely, even ones from simpler clients, that’s fine too and you don’t need to change anything. My 1/4 -> ¼ thing is nothing more than a minor irritation which probably isn’t worth overthinking.

(#gctrz4q) I think realistically the only way to resolve this is to formally support and define a specification for feed formats. The availabl …
I think realistically the only way to resolve this is to formally support and define a specification for feed formats. The available mime types lists two formats that I think are important here. text/plain and text/markdown. I believe a specification that defines and formalizes this so that a feed author can state in their feed that their feed is primar … ⌘ Read more

New repository: aquilax/slide2marpit - Go preset slide to marpit markdown converter

(#2024-09-24T12:45:54Z) @prologic@twtxt.net I’m not really buying this one about readability. It’s easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon

@bender@twtxt.net Ha! Maybe I should get on the Markdown train. You’re taking away my excuses.

@bender@twtxt.net

Sorry, you’re right, I should have used numbers!

I’m don’t understand what “preserve the original hash” could mean other than “make sure there’s still a twt in the feed with that hash”. Maybe the text could be clarified somehow.

I’m also not sure what you mean by markdown already being part of it. Of course people can already use Markdown, just like presumably nothing stopped people from using (twt subjects) before they were formally described. But it’s not universal; e.g. as a jenny user I just see the plain text.

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: …” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

• Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

• “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

• Thanks for phrasing the bit about deletions so neutrally.

• I don’t like the MUST in “Clients MUST follow the chain of reply-to references…”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

• Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

• For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

• Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

• Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

• I’m a little sad about other protocols being not recommended.

• I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

i feel like we should isolate a subset of markdown that makes sense and built it into lextwt. it already has support for links and images. maybe basic formatting bold, italic. possibly block quote and bullet lists. no tables or footnotes

Using Generative AI to Create Runnable Markdown
Explore the innovative realm of AI developer tools with Docker’s GenAI Docker Labs series. Join us as we dive deep into the potential of AI. Discover how generative AI can assist with documentation, project-specific tasks, and more throughout the software lifecycle. Stay updated and get involved with Docker’s latest projects and tools. ⌘ Read more

ReadMeAI: An AI-powered README Generator for Developers
The ReadMeAI tool allows users to upload a code file and describe their project. The tool generates documentation in Markdown code for immediate preview and editing. ⌘ Read more

New York Times Source Code Leaked (and verified)
Over 3.6 Million files totaling over 334 GB. And it’s real. Source code. Documentation. Markdown files. The works. ⌘ Read more

ProcessOne: ejabberd Docs now using MkDocs

Image

The ejabberd Docs website did just get a major rework: new content management system, reorganized navigation, improved markdown, and several improvements!

ejabberd started in November 2002 (see a timeline in the ejabberd turns 20 bl … ⌘ Read more

ProcessOne: ejabberd Docs now using MkDocs
The ejabberd Docs website did just get a major rework: new content management system, reorganized navigation, improved markdown, and several improvements!

ejabberd started in November 2002 (see a timeline in the ejabberd turns 20 blog post). And the first documentation was published in January 2003, using LaTeX, see [Ejabberd Installation and Op … ⌘ Read more

Twtxt spec enhancement proposal thread 🧵

Adding attributes to individual twts similar to adding feed attributes in the heading comments.

https://git.mills.io/yarnsocial/go-lextwt/pulls/17

The basic use case would be for multilingual feeds where there is a default language and some twts will be written a different language.

As seen in the wild: https://eapl.mx/twtxt.txt

The attributes are formatted as [key=value]

They can show up in the twt anywhere it is not enclosed by another element such as codeblock or part of a markdown link.

@eapl.me@eapl.me kinda like the format for markdown images? ![alt](url 'title') ?

Hey Apple, it’s 2023 - about time to start supporting the content indexation of markdown files in Spotlight out of the box, don’t you think?

Hey Apple, it’s 2023 - about time to start supporting the content indexation of markdown files in Spotlight out of the box, don’t you think?

Forked markdown-mode for Emacs ⌘ Read more

@prologic@twtxt.net what do you mean when you say “Docker API”? There are multiple possible meanings for that. podman conforms to some of Docker’s APIs and it’s unclear to me which one you say it’s not conforming to.

You just have to Google “podman Docker API” and you find stuff like this: https://www.redhat.com/sysadmin/podman-rest-api

Podman’s REST API consists of two components:

• A Docker-compatible portion called Compat API
  
• A native portion called Libpod API that provides access to additional features not available in Docker, including pods
  

Or this: https://docs.podman.io/en/latest/markdown/podman-system-service.1.html

The REST API provided by podman system service is split into two parts: a compatibility layer offering support for the Docker v1.40 API, and a Podman-native Libpod layer.

Rebuilding a Solar Powered Website

Image

A screenshot of the markdown file for this page.

During the last months we have been working on switching the solar powered website from one static site generator (Pelican) to another (Hugo). Many readers will not notice the changes right away, as we have not made any major adj … ⌘ Read more

I setup Joplin with caddy as the WebDAV server. Works okay. The e2e encryption can get messed up sometimes. Supports markdown and images.

<darch> how about #markdown links: darch.dk

<SP> image test #markdown

Image

An option would be to have /twtxt.txt be the base functionality as bukket intended without subject tags, markdown, images and such truncated to 140 chars. a /yarn.txt that has all the extentions as we know and love. and maybe a /.well-known/webfinger + (TBD endpoint) that adds on the crypto enhancements that further extend things.

@prologic@twtxt.net The parse is correct. this seems to be something with the markdown render.

The parse is correct. this seems to be something with the markdown render.

https://galusik.fr/log/2022-10-23-new-blog-workflow.html New blog workflow: from markdown to gemtext

In reply to: A simple mess

This is also something people keep getting wrong about Markdown as originally presented. Markdown isn’t a format. It’s a convenience tool that helps you write some of the boringest and commonest parts of HTML easier, and you can easily drop into more wonky HTML at any time.

Yes yes yes yes yes yes! ⌘ Read more

appml/neutrinote

Image

neutriNote - Markdown + Math in Just 3 MB!

Language: Java

Star: 130

Watch: 130 ⌘ Read more

Math support in Markdown
Mathematical expressions are key to information sharing amongst engineers, scientists, data scientists, and mathematicians. Today we are pleased to announce that math expressions can be rendered in Markdown on GitHub using $$ as a delimiter for code blocks with math content or the $ delimiter for inline math expressions. ⌘ Read more

Gemini capsule
Gemini is a lightweight Internet protocol. It’s heavier than Gopher
but lighter than HTTP(S), especially if combined with all other web
technologies. The name makes sense if Gopher is Project Mercury and
the web is the Apollo program.

One of its uses is to serve gemtext, which is a lightweight
Markdown-like markup language, instead of HTML. Gemini browsers don’t
have support for neither Javascript, nor CSS, nor any of the other new
web technologies. It can be beautiful anyway, s … ⌘ Read more

Gemini capsule
Gemini is a lightweight Internet
protocol. It’s heavier than Gopher but a bit lighter than HTTP(S).
It’s the Gemini programme if Gopher is Mercury and HTTP is Atlas.

One of its uses is to serve gemtext, which is a lightweight
Markdown-like markup language, instead of HTML. Gemini browsers don’t
have support for neither Javascript, nor CSS, nor any of the other new
web technologies. It can be beautiful anyway, see for instance
[Lagrange]( [http … ⌘ Read more

Supercharging GitHub Actions with Job Summaries
You can now output and group custom Markdown content on the Actions run summary page. ⌘ Read more

https://framagit.org/Framatophe/md2pdfweazyprint convert markdown to pdf without latex

@ullarah@txt.quisquiliae.com works for me! A tricky bitmight be if it splits within a codeblock so markdown can’t parse

Include diagrams in your Markdown files with Mermaid
A picture tells a thousand words. Now you can quickly create and edit diagrams in markdown using words with Mermaid support in your Markdown files. ⌘ Read more

@fastidious@arrakis.netbros.com the things Gemini has going for it are mutual TLS and lack of JavaScript. Which makes for a secure albeit boring experience (much like gopher). The fake markdown is a bit of a drag.

A render mode for Gemini probably wouldnt be too hard. There are markdown to Gemini libs out there.

With Web3 the whole trust a 3rd party browser ext + high fees + env impact for compute and storage are serious no gos for me.. I have heard one too many horror stories about clicking the wrong link and some script draining your metamask wallet.

What’s new from GitHub Changelog? November 2021 recap
We shipped a ton of updates in November, from the push notification for PR review activities on the go, to an easy way to create Markdown links. ⌘ Read more

@lyse@lyse.isobeef.org So.. in the great wisdom of markdown parser.. it only provides the Title and deletes the alt. :D i guess i could write out the alt and title as the same value

@fastidious@arrakis.netbros.com
The signs show fine on jenny. So, it is a display thing. Probably related to Markdown.

Oof! I found a bug on Yarn’s Markdown rendering, @prologic@twtxt.net. See OP.

@movq@www.uninformativ.de, would you know the regex to use within .muttrc to colorise a Markdown code block like the one below?

# This one works for `code`, but that's about it.
(^|[[:space:][:punct:]])\`[^\`]+\`([[:space:][:punct:]]|$)

@eldersnake@yarn.andrewjvpowell.com There isn’t an equivalent for those because:

Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags.

You can read more of its philosophy at Daring Fireball. There are enhancements to Markdown (CommonMark, for example), that add extra to it.

@movq@www.uninformativ.de To clarify, Markdown is just text. 😊 I can do bolding, link things, and if single return multilines ever comes to jenny, I would be able to do bulleted and numbered lists.

The only things—that I know of—that doesn’t work is “> “, but I can use “>”, like so:

D’oh!

So, jenny allows me to write Markdown almost just fine!

@quark@ferengi.one If so, @movq@www.uninformativ.de, not quite https://www.uninformativ.de/git/jenny/commit/4a02eeec58317107c07e759733312d168e319f17.html#h0-0-5... Markdown needs single new lines for many things. Bulleted, numbered, code, etc. need them.

https://nickjanetakis.com/blog/vim-is-saving-me-hours-of-work-when-writing-books-and-courses markdown vim writing

https://joereynoldsaudio.com/2018/07/07/you-dont-need-vimwiki.html markdown note vim