Searching txt.sour.is

Twts matching #Protocol
Sort by: Newest, Oldest, Most Relevant

ESP32 Bus Pirate Turns Low-Cost Boards into Multi-Protocol Debugging Tools
An open-source project called ESP32 Bus Pirate has been released, inspired by the classic Bus Pirate and adapted for modern ESP32-S3 hardware. Developed by Geo-tp, the firmware transforms low-cost ESP32 boards into versatile debugging devices that can probe, sniff, and interact with a wide range of digital and radio protocols. The firmware supports protocols such […] ⌘ Read more

⤋ Read More

MCP Horror Stories: The Drive-By Localhost Breach
This is Part 4 of our MCP Horror Stories series, where we examine real-world security incidents that expose the devastating vulnerabilities in AI infrastructure and demonstrate how Docker MCP Gateway provides enterprise-grade protection against sophisticated attack vectors. The Model Context Protocol (MCP) has transformed how developers integrate AI agents with their development environments. Tools like… ⌘ Read more

⤋ Read More
In-reply-to » @zvava I am getting [2025/09/11 12:56:01.816] ⇒ please set config.host when trying to run "bbycll". How to bypass that tiny hurdle?

Woot, thank you! Using a config.json like this:

{
  "host": "localhost:31212",
  "protocols": ["http"]
}

Indeed did the trick! I know it isn’t production ready, but I wanted to see with my own eyes, locally, how did it look. :-) I like where you are going! It is looking very nice, and polished. Can’t wait for an alpha, beta, and release!

⤋ Read More
In-reply-to » @prologic @movq My metadata only has my HTTPS URL. I didn't consider having multiple. I was talking about my config.yaml. Jenny sounds like a good client, so I might give that a try.

@dce@hashnix.club No worries 😌 It’s all documented in our soecs, it’s not such a common thing that we’ve felt the great need to really solve, we’re aware folks want to sometimes have their feed on several protocols, and that’s totally fine™ 😅

⤋ Read More
In-reply-to » It might just be my client, but it seems that I cannot track multiple URLs at once. As such, all three of my twtxt URLs will work for following, but mentions will only reach me at my HTTPS URL (https://hashnix.club/~dce/twtxt.txt). If there is a client that can cope with twtxt mirrors, I would love to know about it.

@dce@hashnix.club Ah, oh, well then. 🥴

My client supports that, if you set multiple url = fields in your feed’s metadata (the top-most one must be the “main” URL, that one is used for hashing).

But yeah, multi-protocol feeds can be problematic and some have considered it a mistake to support them. 🤔

⤋ Read More

@lyse@lyse.isobeef.org They are optional dependencies and listed as such:

$ pacman -Qi pinentry
Name            : pinentry
Version         : 1.3.1-5
Description     : Collection of simple PIN or passphrase entry dialogs which
                  utilize the Assuan protocol
Optional Deps   : gcr: GNOME backend [installed]
                  gtk3: GTK backend [installed]
                  qt5-x11extras: Qt5 backend [installed]
                  kwayland5: Qt5 backend
                  kguiaddons: Qt6 backend
                  kwindowsystem: Qt6 backend

And it’s probably a good thing that they’re optional. I wouldn’t want to have all that installed all the time.

⤋ Read More

The WM_CLASS Property is used on X11 to assign rules to certain windows, e.g. “this is a GIMP window, it should appear on workspace number 16.” It consists of two fields, name and class.

Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called app_id.

When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.

Some compositors map name to app_id, others map class to app_id, and even others directly expose the original name and class.

Apparently, there is no consensus.

⤋ Read More
In-reply-to » @bender Both Gopher and Mastodon are a way for me to “babble”. 😅 I basically shut down Gopher in favor of Mastodon/Fedi last year. But the Fediverse doesn’t really work for me. It’s too focused on people (I prefer topics) and I dislike the addictive nature of likes and boosts (I’m not disciplined enough to ignore them). Self-hosting some Fedi thing is also out of the question (the minimalistic daemons don’t really support following hashtags, which is a must-have for me).

@bender@twtxt.net Yeah, well, it’s a bit like twtxt. There is a Gopher community, but it’s small. I actually don’t like that HTTP is so easily accessible. I don’t like it that much when people post links to my site on HackerNews or something like that. Too much exposure.

Gopher is a small world. It’s slow and cozy.

And much like twtxt, the protocol is simple®, so it’s easier to tinker with it.

⤋ Read More

When I chose the MIT license for all of my software, I thought:

“Should I use GPL, which I don’t really understand? Is that worth it? Yeah, there is a theoretical possibility that some company might use my code in their proprietary product … and then what? Should I sue them to enforce the GPL? I’m not going to do that anyway, so I’ll just use the MIT license.”

And now we have those LLM scrapers and now it’s suddenly a reality that these companies (ab)use my code. I can see it in my logs. I didn’t expect that back then.

GPL wouldn’t help, either, of course. (Regardless, I now think that GPL would have been the better choice anyway.)

I’m honestly considering taking my code and website offline. Maybe make it accessible through some obscure protocol like Gopher or Gemini, but no more HTTP.

(Yes, Anubis might help. Temporarily.)

I’m just tired.

⤋ Read More

[$] System-wide encrypted DNS
The increasing sophistication of attackers has organizations
realizing that perimeter-based security models are inadequate. Many
are planning to transition their internal networks to a zero-trust\
architecture. This requires every communication on the network to
be encrypted, authenticated, and authorized. This can be achieved in
applications and services by using modern communication
protocols. However, the world still depends on Domain Name Syste … ⌘ Read more

⤋ Read More

MCP Server 的五種主流架構與 Nacos 的選擇
在 AI 大模型應用爆發的今天,Model Context Protocol (MCP) 作爲連接 AI 大模型與應用的關鍵協議,正在快速普及。然而,如何在企業級環境中高效部署和管理 MCP 服務,成爲技術團隊面臨的重要挑戰。本文將深入剖析 MCP Server 的五種主流架構模式,並結合 Nacos 服務治理框架,爲企業級 MCP 部署提供實用指南。MCP 架構的演進與挑戰MCP 協議爲 AI ⌘ Read more

⤋ Read More

MCP 超強源碼解讀!Streamable HTTP 如何實現服務端向客戶端通信
在最新的 Model Context Protocol(MCP,模型上下文協議)版本(2025-03-26)[1] 中引入了 Streamable HTTP 的通信方式,取代了舊版本中的 SSE 通信方式,成爲了新的遠程 MCP 調用標準。Streamable HTTP 通信下的 client 向 server 的請求不需要像之前必須保持 SSE 的長連接,而是通過 client 發起 HTTP ⌘ Read more

⤋ Read More

如何把 ASP-NET Core WebApi 打造成 Mcp Server
前言    MCP (Model Context Protocol) 即模型上下文協議目前不要太火爆了,關於它是什麼相信大家已經很熟悉了。目前主流的 AI 開發框架和 AI 工具都支持集成MCP,這也正是它的意義所在。畢竟作爲一個標準的協議,當然是更多的生態接入進來纔會有意義。使用 MCP 我們可以把Tools調用標準化,這意味着我們可以忽略語言、框架快速把工具融合到不同的模型中去。現在,如何把現 ⌘ Read more

⤋ Read More

給 MCP 加上 RAG,工具準確率提升 200-,起飛~
大型語言模型(LLMs)在有效利用越來越多的外部工具(如模型上下文協議(MCP)所定義的工具)方面存在困難,這是由於提示膨脹和選擇複雜性造成的。因此引入了 RAG-MCP,這是一個檢索增強生成框架,通過卸載工具發現來克服這一挑戰。提示膨脹與 MCP 壓力測試提示膨脹問題:隨着可用的 MCP(Model Context Protocol)服務器數量增加,將所有工具描述包含在單個提示中會導致提示過長, ⌘ Read more

⤋ Read More

Securing Model Context Protocol: Safer Agentic AI with Containers
Model Context Protocol (MCP) tools remain primarily in the hands of early adopters, but broader adoption is accelerating. Alongside this growth, MCP security concerns are becoming more urgent. By increasing agent autonomy, MCP tools introduce new risks related to misalignment between agent behavior and user expectations and uncontrolled execution. These systems also present a novel… ⌘ Read more

⤋ Read More

GhidraMCP 搭建及核心源碼閱讀
前言–手動逆向太費勁了 想找個 AI 助手幫我逆向一下 逛 github 的時候看到了一個 GhidraMCP 於是打算拿來用用 所以本文記錄一下 GhidraMCP 搭建以及源碼解析什麼是 MCP——-MCP(Model Context Protocol,模型上下文協議)是一種開放協議,旨在實現 大型語言模型(LLM) 應用與外部數據源、工具和服務之間的無縫集成,類似於網絡中的 HTT ⌘ Read more

⤋ Read More

(Updated) ESP32-C5-DevKitC-1 with 240MHz RISC-V Processor, Zigbee, and Thread Connectivity
The ESP32-C5-DevKitC-1 is another upcoming entry-level development board designed for IoT applications, featuring the ESP32-C5-WROOM-1 module. This board supports key wireless protocols, including Wi-Fi 6 (2.4 GHz and 5 GHz), Bluetooth LE 5, Zigbee, and Thread. The ESP32-C5-WROOM-1 module is equipped with a 32-bit RISC-V single-core processor running at 240 MHz along … ⌘ Read more

⤋ Read More

Introducing Docker MCP Catalog and Toolkit: The Simple and Secure Way to Power AI Agents with MCP Tools
Model Context Protocols (MCPs) are quickly becoming the standard for connecting AI agents to external tools, but the developer experience hasn’t caught up. Discovery is fragmented, setup is clunky, and security is too often bolted on last. Fixing this experience isn’t a solo mission—it will take an industry-wide effort. A secure, scalable, and trusted MCP… ⌘ Read more

⤋ Read More
In-reply-to » I've just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I'll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs. I don't know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it's always important to be grateful. Thanks to @prologic @movq @eapl.me @bender @aelaraji @arne @david @lyse @doesnm @xuu @sorenpeter for everything you have taught me. I've learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure! What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It's not a replacement for any technology, it's just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don't expect anyone to use it, but feedback is always welcome. Best regards to everyone. #twtxt #emacs #twtxt-el #texudus

@andros@twtxt.andros.dev Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients.
What about using Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I’m still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

⤋ Read More

LILYGO T-Echo Lite Offers Integrated LoRa, GNSS, and E-Paper Display in Compact Form
The LILYGO T-Echo Lite is a compact wireless development board designed for embedded applications that require long-range communication, positioning, and low-power display capabilities. Built around the Nordic nRF52840 microcontroller, the platform supports a wide range of wireless protocols and is available in several hardware configurations. The main processing component is t … ⌘ Read more

⤋ Read More
In-reply-to » Confession:

@movq@www.uninformativ.de @kat@yarn.girlonthemoon.xyz @quark@ferengi.one In 2014 one person created protocol ii. Later it forked in IDEC. Why i said this? Because it’s simple “federated” forum-like protocol where from your station fetch another every 5-10 minutes. Stations has topic-based channels like idec.talks, linux.16, haiku.os, zx.spectrum. In short it’s FIDO but.. more modern? Documentation: https://github.com/idec-net/new-docs (mostly Russian, but you can use translator, also protocol already translated to english)

⤋ Read More

Confession:

I’ve never found microblogging like twtxt or the Fediverse or any other “modern” social media to be truly fulfilling/satisfying.

The reason is that it is focused so much on people. You follow this or that person, everybody spends time making a nice profile page, the posts are all very “ego-centric”. Seriously, it feels like everybody is on an ego-trip all the time (this is much worse on the Fediverse, not so much here on twtxt).

I miss the days of topic-based forums/groups. A Linux forum here, a forum about programming there, another one about a certain game. Stuff like that. That was really great – and it didn’t even suffer from the need to federate.

Sadly, most of these forums are dead now. Especially the nerds spend a lot of time on the Fediverse now and have abandoned forums almost completely.

On Mastodon, you can follow hashtags, which somewhat emulates a topic-based experience. But it’s not that great and the protocol isn’t meant to be used that way (just read the snac2 docs on this issue). And the concept of “likes” has eliminated lots of the actual user interaction. ☹️

⤋ Read More
In-reply-to » Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

that said, and reading to @sorenpeter@darch.dk and @andros@twtxt.andros.dev I have new thoughts. I assume that this won’t change anyone’s opinions or priorities, so it makes no harm sharing them.

It’s always tempting to use something that already exists (like X, Masto, Bsky, etc.) rather that building anything through effort and disagreement until reaching to something useful and valuable together. A ‘social service’ is only useful if people is using it.

I’ll add that I haven’t lost interest on the ‘hacky’ part of twtxt about developing tools, protocols, and extensions as a community. It’s the appealing part! It’s a nice hobby to have, shared with random people across the world.
But this is not the right way for me, and makes me feel that I’m unwelcome to propose something different (after watching replies to my previous twt). Feels like “If you don’t agree, you are free to leave, we’ll miss you.” Naah, not cool. I’ve lived that many times before, and nowadays I don’t have enough spare time and energy for a hobby like that.

Let’s see what happens next with the micro-community!

⤋ Read More

從 0 開始實現 MCP-Client
什麼是 MCP-Client?MCP-Client是Model Context Protocol(模型上下文協議)架構中的一個重要組件,用於連接AI模型(如Claude、GPT等大型語言模型)與外部數據源、工具和服務的橋樑。MCP(Model Context Protocol)是由Anthropic公司在 2024 年底首次提出並開源的一種開放標準協議,旨在解決大語言模型(LLM)與外部世界的連接 ⌘ Read more

⤋ Read More

Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation

⤋ Read More

AnalogLamb Expands Maple Series with Low-Cost ESP32C6 Breakout Boards
AnalogLamb has introduced three new RISC-V development boards based on the ESP32-C6, designed for low-cost, full-function, and low-power IoT applications. These boards feature Espressif’s first Wi-Fi 6 SoC, integrating Wi-Fi 6 (2.4 GHz), Bluetooth 5 LE, and IEEE 802.15.4 protocols. Each board is built around the ESP32-C6-WROOM-1 module, which combines a high-performance 32-bit RISC-V core […] ⌘ Read more

⤋ Read More

NUCLEO-WBA65RI Brings Bluetooth LE, Thread, and Zephyr RTOS to STM32 Nucleo-64 Platform
The NUCLEO-WBA65RI is a wireless STM32 Nucleo-64 development board built around the STM32WBA65RIV7 microcontroller. It combines the MB2130 MCU RF board with the MB1801 mezzanine board to support Bluetooth LE and IEEE 802.15.4-based protocols such as Thread, Matter, and Zigbee. The STM32WBA65RIV7 microcontroller is a 32-bit Arm Cortex-M33 device featuring 2 MB of flash and … ⌘ Read more

⤋ Read More

How to build and deliver an MCP server for production
In December of 2024, we published a blog with Anthropic about their totally new spec (back then) to run tools with AI agents: the Model Context Protocol, or MCP. Since then, we’ve seen an explosion in developer appetite to build, share, and run their tools with Agentic AI – all using MCP. We’ve seen new […] ⌘ Read more

⤋ Read More

I’m thinking of building a hardened peering protocol for Yarn.social’s yarnd: pods establish cryptographic identities, exchange signed /info and /twt payloads with signature verification, ensuring authenticity, integrity, and spoof-proof identity validation across the distributed network.

⤋ Read More

用 Go 語言打造高併發 MCP 服務器:理論、實戰與 AI 應用全景探索
在這個 AI 與大數據時代,構建一個高性能、可擴展的 MCP(Modular/Model Context Protocol)服務器已成爲打通應用與 AI 模型之間數據孤島的重要橋樑。本文將帶你深入瞭解 MCP 協議的設計理念、使用 Go 語言實現 MCP 服務器的詳細流程,以及 MCP 如何爲 AI 應用提供類似 USB-C 接口般的統一連接能力。 “MCP 提供統一的數據交換框架,幫助企業實 ⌘ Read more

⤋ Read More

如何用 go 搭建 MCP 服務
什麼是 MCP?———–MCP 是 “模型上下文協議(Model Context Protocol)” 的簡稱,用一句簡單通俗易懂的話描述:是一種讓 AI 模型能夠無縫連接到外部工具和數據源的標準化方式。想象它就像 AI 的“萬能接口”,能讓 AI 像用 USB 線連接設備一樣,輕鬆調用其他程序或服務。官方 MCP 架構圖————-MCP Hosts: 是指 LLM ⌘ Read more

⤋ Read More

用 Go 語言輕鬆構建 MCP 客戶端與服務器
★ 該文章已被 Model Context Protocol(MCP) 中文教程講解  收錄,歡迎 star 收藏。 若想獲取可執行的完整項目代碼,可關注本公衆號,回覆 MCP。前言模型上下文協議(Model Context Protocol,簡稱 MCP)是一種開放標準,旨在標準化大型語言模型(LLM)與外部數據源和工具之間的交互方式。隨着 MCP 越來越受歡迎,Go MCP 庫 ⌘ Read more

⤋ Read More

10 Logistical Secrets Behind the World’s Most Massive Events
From the Olympics to royal funerals to music festivals that transform entire landscapes, some events push human coordination to its limits. But behind the public spectacle lies a world of strategic planning, military-grade operations, and bizarre contingency protocols. These events aren’t just big—they’re logistical marvels, requiring teams to manage millions of people, thousands of moving […]

The post [10 Logis … ⌘ Read more

⤋ Read More

使用 Go 構建 MCP Server
一、MCP 介紹 ———1. 基本介紹 MCP(Model Context Protocol,模型上下文協議)是由 Anthropic 公司(Claude 大模型的創造者)於 2024 年 11 月推出的一種開放標準協議,旨在統一大型語言模型(LLM)與外部數據源和工具之間的通信方式。MCP 的核心目標是解決當前 AI 應用開發中的數據孤島和碎片化集成問題。2. 協議特點 MCP 可以 ⌘ Read more

⤋ Read More
In-reply-to » My twtxt feed is now also available at gemini://roccodrom.de/twtxt.txt

well, I assume by syntax you mean Gemtext (which I like a lot, my personal blog is built on top of it), so I think it might work for twtxt clients…

I knew of twtxt in Gemini Antenna, so at least the 2017 spec might work on that protocol. I think the main issue with extensions is that they weren’t designed with many URLs and protocols in mind.

Also I have to admit that the Gemini community significantly reduced in the last few years. I don’t know how worth it is to add support for Gemini now.

⤋ Read More
In-reply-to » What is twtxt for me? It is a community of users sharing plain text following a specification that can be readable by both humans and machines.

well… it has been an opportunity to build an artisanal microblogging client on top of a minimalist protocol. I agree on the hacker toy part.

And of course it’s about being part of a niche community which is (mostly) amazing, and nurturing. As there is almost no one writing in my native spanish, it has been an interesting challenge to share my thoughts in english, as well.

I couldn’t say it’s a ‘social network’ per se, I think it lack many engagement things usually associated with social networks, although it has a social part of igniting discussions, learnings and behavioral changes, which is the meaning of social for me.

⤋ Read More

Apple to Support Encrypted RCS Messaging in Future Software Update
Apple says it will add support for a new Rich Communication Services ( RCS) specification that includes end-to-end encryption (E2EE) for messages sent over the protocol in future software updates.

Image

“End-to-end encryption is a powerful privacy and security technology that iMessage has supported since the … ⌘ Read more

⤋ Read More

MCP 實戰:使用 Go 快速構建 MCP Server
MCP 簡介MCP 協議(Model Context Protocol,模型上下文協議)是由 Anthropic 於 2024 年 11 月底推出的一種開放標準,旨在統一大型語言模型(LLM)與外部數據源和工具之間的通信。官方地址 https://modelcontextprotocol.io 架構如下 MCP 協議的架構包含多個關鍵組件:Host(宿主程序)、MCP Client(M ⌘ Read more

⤋ Read More

jeffro256 submits CCS proposal for 3 months of Monero/Carrot dev work
jeffro2561 has submitted a new CCS proposal2 looking to continue working full-time on Carrot 3 development - Monero’s main addressing protocol post-FCMP++ - for 3 months (Q1 2025):

The last quarter I implemented the core cryptography for Carrot. [..] The FCMP++ integration and Carrot integration are finally meeting ends and are almost ready for hot path integration. … ⌘ Read more

⤋ Read More
In-reply-to » I haven't read the entire specification, but I think there is a fundamental design problem. Why would someone put an encrypted message on a public feed that is completely useless to everybody other than the one recipient? This doesn't make sense to me. It of course depends on the threat model, but wouldn't one also want to minimize the publicly visible metadata (who is communicating with whom and when) when privately messaging? I feel there are better ways to accomplish this. Sorry, if I miss the obvious use case, please let me know. :-)

It’s ok for most encrypted protocols (In salty you can fetch other messages but can’t decrypt). Btw i think recipient can be removed so if someone seen message they tried to decypt, if can’t - its not message to you

⤋ Read More

I was using my 5G router setup with Vanilla OpenWRT and QMI Cellular as a protocol for quite some time, but there were irregular disconnections etc. Updating the firmware of the modem didn’t help. Some days ago, I noticed that it’s also possible to configure with Modem Manager (which provides connection information directly in LuCI) and put the Quectel modem into MBIM mode. It’s running without hiccups now! Also updated to OpenWRT 24.10. ⌘ Read more

⤋ Read More

The Model Context Protocol: Simplifying Building AI apps with Anthropic Claude Desktop and Docker
Anthropic recently unveiled the Model Context Protocol (MCP), a new standard for connecting AI assistants and models to reliable data and tools. However, packaging and distributing MCP servers is very challenging due to complex environment setups across multiple architectures and operating systems. Docker is the perfect solution for this – it allo … ⌘ Read more

⤋ Read More

使用 Buf 和 Nix 構建 Go 語言 gRPC 服務
在本文中,我們將探討如何在 Go 中構建一個可擴展且易於管理的 gRPC 服務。我們將使用 Buf 來管理 Protocol Buffers(Protobuf),並藉助 Nix 創建一個一致且可復現的開發環境。Buf 提供了一種高效且有組織的方式來管理 Protobuf,而 Nix 則確保開發環境在不同系統之間的一致性。通過本指南的學習,你將能夠構建一個具有清晰代碼結構和良好可維護性的完整 gRP ⌘ Read more

⤋ Read More

$6.80 LILYGO T7-C6 Board Leverages RISC-V Single-Core Processor & 4MB Integrated Flash Memory
The LILYGO T7-C6 is a compact development board built around the ESP32-C6-MINI-1 module, offering versatile features designed for IoT and wireless communication applications. The board is available with either an onboard PCB antenna or an external antenna and supports modern wireless protocols, including 2.4 GHz Wi-Fi 6, Bluetooth 5 (LE), and IEEE 802.15.4. The … ⌘ Read more

⤋ Read More

One benefit with bluesky is your username is also a website. And not a clunky URL with slashes and such. I wish twtxt adopted that. I have advocated for webfinger to for twtxt to let us do something like it with usernames. Nostr has something like it

By default the bsky.social urls all redirect to their feeds like: hmpxvt.bsky.social
Many custom urls will redirect to some kind of linktree or just their feed cwebonline.com or la.bonne.petite.sour.is or if you are a major outlet just to your web presence like https://theonion.com‬ or https://netflix.com

Its just good SEO practice

Do all nostr addresses take you to the person if typed into a browser? That is the secret sauce.
No having to go to some random page first. no accounts. no apps to install. just direct to the person.

⤋ Read More

One benefit with bluesky is your username is also a website. And not a clunky URL with slashes and such. I wish twtxt adopted that. I have advocated for webfinger to for twtxt to let us do something like it with usernames. Nostr has something like it

By default the bsky.social urls all redirect to their feeds like: hmpxvt.bsky.social
Many custom urls will redirect to some kind of linktree or just their feed cwebonline.com or la.bonne.petite.sour.is or if you are a major outlet just to your web presence like https://theonion.com‬ or https://netflix.com

Its just good SEO practice

Do all nostr addresses take you to the person if typed into a browser? That is the secret sauce.
No having to go to some random page first. no accounts. no apps to install. just direct to the person.

⤋ Read More

iSG Display Max Gateway for Smart Home Automation with Matter and Zigbee
AmeriDroid recently featured the iSG Display Max Gateway, a flexible platform designed to streamline smart home management and automation. With its 10-inch display and support for Wi-Fi and Bluetooth Low Energy, the gateway integrates multiple protocols to offer flexibility for diverse smart home setups. The device is powered by an eight-core processor, although specific details […] ⌘ Read more

⤋ Read More
In-reply-to » Righto, @eapl.me, ta for the writeup. Here we go. :-)

@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?

⤋ Read More

Forlinx FET MX95xx C System on Module for Industrial and IoT Applications
Forlinx Embedded has introduced the FET-MX95xx-C System on Module, built around the high-performance NXP i.MX95xx processor for industrial, automotive, and IoT applications. Key features include a 10GbE port, dual GbE ports, CAN interfaces, camera support, and multiple wireless protocols. Unlike the FET3562J-C SoM, this new Forlinx device is powered by the NXP i.MX95xx processor. It […] ⌘ Read more

⤋ Read More
In-reply-to » I've been thinking of a few improvements for the next generation of twtxt spec, let me know if these are useful or interesting :) https://text.eapl.mx/a-few-ideas-for-a-next-twtxt-version

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

⤋ Read More
In-reply-to » Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

@movq@www.uninformativ.de How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?

⤋ Read More

Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

  1. It’s a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.

  2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.

  3. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).

  4. Do we need more commandments?

⤋ Read More

ESP32-C5-DevKitC-1 with 240MHz RISC-V Processor, Zigbee, and Thread Connectivity
The ESP32-C5-DevKitC-1 is another upcoming entry-level development board designed for IoT applications, featuring the ESP32-C5-WROOM-1 module. This board supports key wireless protocols, including Wi-Fi 6 (2.4 GHz and 5 GHz), Bluetooth LE 5, Zigbee, and Thread. The ESP32-C5-WROOM-1 module is equipped with a 32-bit RISC-V single-core processor running at 240 MHz along with 384 KB […] ⌘ Read more

⤋ Read More

ofrnxmr completes first milestone for BasicSwapDEX CCS proposal
ofrnxmr1 has completed2 the first milestone (M1-O/M1-F/M1-B) for their CCS proposal3 to empower and steward BasicSwapDex4 to production quality software:

Work overview

”`
Core v0.13.4 > v0.14.1:

  • Update coincurve fork and rebase onto v20
  • Include coincurve as a basicswap dependency
  • Fix remote (local) node handling
  • Started integration of the novel BCH <>XMR swap protocol
    … ⌘ Read more”`

⤋ Read More

Kewbit posts first progress report for ‘Haveno App’ CCS proposal
Kewbit1 has posted the first progress report2 for their CCS proposal to continue developing the Haveno App 3 (previously known as Haveno Plus):

Focusing specifically on the Protocol Interface milestone, I have implemented the full scope of gPRC interfacing in Dart and already hooked a considerable amount of it into the app itself, almost to the point of completion [..] Thank you for your … ⌘ Read more

⤋ Read More
In-reply-to » This is only first draft quality, but I made some notes on the #twtxt v2 proposal. http://a.9srv.net/b/2024-09-25

@anth@a.9srv.net you wrote:

“Edits and Deletions should go; see also Section 6. This is probably the worst example of this document pushing a text document to do more protocol-like things.”

Edit and deletions are precisely what brought us here. Currently, if one replies to a twtxt, and the original gets later edited, it breaks replies, and potentially drastically changes context.

⤋ Read More
In-reply-to » Okay folks, I've spent all day on this today, and I think its in "good enough"™ shape to share:

@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.

⤋ Read More
In-reply-to » Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to add stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.

⤋ Read More
In-reply-to » Something odd just happened to my twtxt timeline... A bunch of twts dissapered, others were marked to be deleted in mutt. so I nuked my whole twtxt Maildir and deleted my ~/.cache/jenny in order to start with a fresh Pull. I pulled feed as usual. Now like HALF the twts aren't there 😂 even my my last replay. WTF IS GOING ON? 🤣🤣🤣

More:

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Notice the difference? Soren edited, and broke everything.

⤋ Read More
In-reply-to » @prologic Some criticisms and a possible alternative direction:

The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be… Maybe it doesn’t have to bee that stick?

Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:

  1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
  2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
  3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)

I know it’s longer that 7-11 characters, but it’s self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:

Is this something that would work?

⤋ Read More
In-reply-to » @falsifian In my opinion it was a mistake that we defined the first url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:

I was not suggesting to that everyone need to setup a working webfinger endpoint, but that we take the format of nick+(sub)domain as base for generating the hashed together with the message date and content.

If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt … damn I just notice the gemini. subdomain.

Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?

⤋ Read More
In-reply-to » Interesting.. QUIC isn't very quick over fast internet.

@xuu@txt.sour.is Thanks for the link. I found a pdf on one of the authors’ home pages: https://ahmadhassandebugs.github.io/assets/pdf/quic_www24.pdf . I wonder how the protocol was evaluated closer to the time it became a standard, and whether anything has changed. I wonder if network speeds have grown faster than CPU speeds since then. The paper says the performance is around the same below around 600 Mbps.

To be fair, I don’t think QUIC was ever expected to be faster for transferring a single stream of data. I think QUIC is supposed to reduce the impact of a dropped packet by making sure it only affects the stream it’s part of. I imagine QUIC still has that advantage, and this paper is showing the other side of a tradeoff.

⤋ Read More
In-reply-to » On the Subject of Feed Identities; I propose the following:

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

⤋ Read More
In-reply-to » On the Subject of Feed Identities; I propose the following:

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

⤋ Read More
In-reply-to » Does anyone know what the differences between HTTP/1.1 HTTP/2 and HTTP/3 are? 🤔

HTTP/2 differs from 1.x by becoming a binary protocol, it also multiplexes multiple channels over the same connection and has the ability to prefetch related content to the browser to lower the perceived latency.

HTTP/3 moves the binary protocol from HTTP/2 over to QUIC which is based on UDP instead of TCP. This makes it better suited to mobile or unstable networks where handling of transmission errors can be handled at a higher level.

⤋ Read More
In-reply-to » Does anyone know what the differences between HTTP/1.1 HTTP/2 and HTTP/3 are? 🤔

HTTP/2 differs from 1.x by becoming a binary protocol, it also multiplexes multiple channels over the same connection and has the ability to prefetch related content to the browser to lower the perceived latency.

HTTP/3 moves the binary protocol from HTTP/2 over to QUIC which is based on UDP instead of TCP. This makes it better suited to mobile or unstable networks where handling of transmission errors can be handled at a higher level.

⤋ Read More