technically I can put the Bridge verificaiton code in my feed’s metadata so no-one really ever sees or notices it 🤔 Maybe I’ll add a first-class button/field thingy in yarnd so users can “register their feed” straight from their pod? 🤔

Bcachefs Rolls Out Metadata Version Reconcile “rebalance_v2” Feature
For those making use of the out-of-tree Bcachefs file-system driver, rolling out to the snapshot/nightly testing channel is the long-in-development “rebalance_v2” functionality now known as the “bcachefs_metadata_version_reconcile” feature… ⌘ Read more

No, I was using an empty hash URL when the feed didn’t specify a url metadata. Now I’m correctly falling back to the feed URL.

whoo fix a long stnading bug with identicons for feeds with no avatar in their metadata

Hint:

# nick = ...
# avatar = ...

Oh, and I forgot (because I thought it was obvious, my bad), set a nick, and a url at the very minimum on your feed. See “Metadata Extension”.

Wireshark 4.6.0 Supports macOS Pktap Metadata (PID, Process Name, etc.)
Comments ⌘ Read more

I think I’m just about ready to go live with my new blog (migrated from MicroPub). I just finished migrating all of the content over, fixing up metadata, cleaning up, migrating media, optimizing media.

The new blog for prologic.blog soon to be powered by zs using the zs-blog-template is coming along very nicely 👌 It was actually pretty easy to do the migration/conversation in the end. The results are not to shabby either.

Before:

• ~50MB repo
  
• ~267 files
  

After:

• ~20MB repo
  
• ~88 files

@bender@twtxt.net Ahh yes I see what you mean. no indicate of when the post was made right? That should be ideally displayed on the page somewhere? Would you expect it in the url as well, because not having /posts/yyyy/mm/dd/.... was actually intentional. But yeah I should figure out where to put some additional metadata on the page.

@zvava@twtxt.net Good question. This is the spec, I think:

https://twtxt.dev/exts/metadata.html#nick

It doesn’t say much. 🤔

In the wild, I’ve only seen “traditional” nick names, i.e. ASCII 0x21 thru 0x7E.

My client removes anything but r'[a-zA-Z0-9]' from nick names.

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

@prologic@twtxt.net Yeah, this really could use a proper definition or a “manifest”. 😅 Many of these ideas are not very wide spread. And I haven’t come across similar projects in all these years.

Let’s take the farbfeld image format as an example again. I think this captures the “spirit” quite well, because this isn’t even about code.

This is the entire farbfeld spec:

farbfeld is a lossless image format which is easy to parse, pipe and compress. It has the following format:

╔════════╤═════════════════════════════════════════════════════════╗
║ Bytes  │ Description                                             ║
╠════════╪═════════════════════════════════════════════════════════╣
║ 8      │ "farbfeld" magic value                                  ║
╟────────┼─────────────────────────────────────────────────────────╢
║ 4      │ 32-Bit BE unsigned integer (width)                      ║
╟────────┼─────────────────────────────────────────────────────────╢
║ 4      │ 32-Bit BE unsigned integer (height)                     ║
╟────────┼─────────────────────────────────────────────────────────╢
║ [2222] │ 4x16-Bit BE unsigned integers [RGBA] / pixel, row-major ║
╚════════╧═════════════════════════════════════════════════════════╝

The RGB-data should be sRGB for best interoperability and not alpha-premultiplied.

(Now, I don’t know if your screen reader can work with this. Let me know if it doesn’t.)

I think these are some of the properties worth mentioning:

• The spec is extremely short. You can read this in under a minute and fully understand it. That alone is gold.
  
• There are no “knobs”: It’s just a single version, it’s not like there’s also an 8-bit color depth version and one for 16-bit and one for extra large images and one that supports layers and so on. This makes it much easier to implement a fully compliant program.
  
• Despite being so simple, it’s useful. I’ve used it in various programs, like my window manager, my status bars, some toy programs like “tuxeyes” (an Xeyes variant), or Advent of Code.
  
• The format does not include compression because it doesn’t need to. Just use something like bzip2 to get file sizes similar to PNG.
  
• It doesn’t cover every use case under the sun, but it does cover the most important ones (imho). They have discussed using something other than RGBA and decided it’s not worth the trouble.
  
• They refrained from adding extra baggage like metadata. It would have needlessly complicated things.

Reducing Cargo target directory size with -Zno-embed-metadata
Comments ⌘ Read more

SSRF via PDF Generator? Yes, and It Led to EC2 Metadata Access

Image

👨‍💻Free Article Link

[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/ssrf-via-pdf-generator-yes-and-it-led-to-ec2-metadata-access-39b8e5b41840 … ⌘ Read more

Microsoft changes pre-production driver signing, ends the device metadata service
As the headline suggests, we’re going to be talking about some very dry Windows stuff that only affects a relatively small number of people, but for those people this is a big deal they need to address. If you’re working on pre-production drivers that need to be signed, this is important to you. The Windows Hardware Program supports partners signing drivers for use in pr … ⌘ Read more

hmm i need to start storing feed preambles so i can capture metadata like that

For point 1 and others using the metadata tags. we have implemented them in yarnd as [lang=en][meta=data]

Lol, seems yarn do not display metadata on @terron@duque-terron.cat

You are right: no advantage. Also your method can make backward compatible to feeds which doesn’t implement metadata extension

Introducing Annotated Logger: A Python package to aid in adding metadata to logs
We’re open sourcing Annotated Logger, a Python package that helps make logs searchable with consistent metadata.

The post [Introducing Annotated Logger: A Python package to aid in adding metadata to logs](https://github.blog/developer-skills/programming-languages-and-frameworks/introducing-annotated-logger-a-python-package-to-aid-in-a … ⌘ Read more

Lol, metadata extension should be optional for backward-compability

@eapl.me@eapl.me Neat.

So for twt metadata the lextwt parser currently supports values in the form [key=value]

https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/parser_test.go#L692-L698

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

So, @prologic@twtxt.net, Yarn isn’t rendering the metadata as described on the format documentation. That is, ux2028 is ignored when Yarn renders the description metadata.

Web interface is deleted in https://git.mills.io/saltyim/saltyim/commit/376de2702319686c902ec03b8ca1e17b020fc639 but seems incorrectly (in source i see git lfs metadata). Can be builded if you grab https://git.mills.io/saltyim/saltyim/src/commit/15a64de82829/internal/web/app.wasm and place it in source (go directory has cached source) and rebuild

@2024-10-08T19:36:38-07:00@a.9srv.net Thanks for the followup. I agrees with most of it - especially:

Please nobody suggest sticking the content type in more metadata. 🙄

Yes, URL can be considered ugly, but they work and are understandable by both humans and machines. And its trivial for any client to hide the URLs used as reference in replies/treading.

Webfinger can be an add-on to help lookup people, and it can be made independent of the nick by just serving the same json regardless of the nick as people do with static sites and a as I implemented it on darch.dk (wf endpoint). Try RANDOMSTRING@darch.dk on http://darch.dk/wf-lookup.php (wf lookup) or RANDOMSTRING@garrido.io on https://webfinger.net

@prologic@twtxt.net

See https://dev.twtxt.net

Yes, that is exactly what I meant. I like that collection and “twtxt v2” feels like a departure.

Maybe there’s an advantage to grouping it into one spec, but IMO that shouldn’t be done at the same time as introducing new untested ideas.

See https://yarn.social (especially this section: https://yarn.social/#self-host) – It really doesn’t get much simpler than this 🤣

Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)

That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)

@david@collantes.us Thanks, that’s good feedback to have. I wonder to what extent this already exists in registry servers and yarn pods. I haven’t really tried digging into the past in either one.

How interested would you be in changes in metadata and other comments in the feeds? I’m thinking of just permanently saving every version of each twtxt file that gets pulled, not just the twts. It wouldn’t be hard to do (though presenting the information in a sensible way is another matter). Compression should make storage a non-issue unless someone does something weird with their feed like shuffle the comments around every time I fetch it.

@prologic@twtxt.net

(#w4chkna) @falsifian@www.falsifian.org You mean the idea of being able to inline # url = changes in your feed?

Yes, that one. But @lyse@lyse.isobeef.org pointed out suffers a compatibility issue, since currently the first listed url is used for hashing, not the last. Unless your feed is in reverse chronological order. Heh, I guess another metadata field could indicate which version to use.

Or maybe url changes could somehow be combined with the archive feeds extension? Could the url metadata field be local to each archive file, so that to switch to a new url all you need to do is archive everything you’ve got and start a new file at the new url?

I don’t think it’s that likely my feed url will change.

@prologic@twtxt.net Some criticisms and a possible alternative direction:

1. Key rotation. I’m not a security person, but my understanding is that it’s good to be able to give keys an expiry date and replace them with new ones periodically.

2. It makes maintaining a feed more complicated. Now instead of just needing to put a file on a web server (and scan the logs for user agents) I also need to do this. What brought me to twtxt was its radical simplicity.

Instead, maybe we should think about a way to allow old urls to be rotated out? Like, my metadata could somehow say that X used to be my primary URL, but going forward from date D onward my primary url is Y. (Or, if you really want to use public key cryptography, maybe something similar could be used for key rotation there.)

It’s nice that your scheme would add a way to verify the twts you download, but https is supposed to do that anyway. If you don’t trust https to do that (maybe you don’t like relying on root CAs?) then maybe your preferred solution should be reflected by your primary feed url. E.g. if you prefer the security offered by IPFS, then maybe an IPNS url would do the trick. The fact that feed locations are URLs gives some flexibility. (But then rotation is still an issue, if I understand ipns right.)

@prologic@twtxt.net Fair enough! I just added some metadata.

Thanks for your feedback @lyse@lyse.isobeef.org. For some reason i missed it until now. For now I have implemented endpoint discovery for #webmentions as a metadata field in the twtxt.txt like this:
# webmention = http://darch.dk/timeline/webmention

An official FBI document dated January 2021, obtained by the American association “Property of People” through the Freedom of Information Act.

This document summarizes the possibilities for legal access to data from nine instant messaging services: iMessage, Line, Signal, Telegram, Threema, Viber, WeChat, WhatsApp and Wickr. For each software, different judicial methods are explored, such as subpoena, search warrant, active collection of communications metadata (“Pen Register”) or connection data retention law (“18 USC§2703”). Here, in essence, is the information the FBI says it can retrieve:

• Apple iMessage: basic subscriber data; in the case of an iPhone user, investigators may be able to get their hands on message content if the user uses iCloud to synchronize iMessage messages or to back up data on their phone.

• Line: account data (image, username, e-mail address, phone number, Line ID, creation date, usage data, etc.); if the user has not activated end-to-end encryption, investigators can retrieve the texts of exchanges over a seven-day period, but not other data (audio, video, images, location).

• Signal: date and time of account creation and date of last connection.

• Telegram: IP address and phone number for investigations into confirmed terrorists, otherwise nothing.

• Threema: cryptographic fingerprint of phone number and e-mail address, push service tokens if used, public key, account creation date, last connection date.

• Viber: account data and IP address used to create the account; investigators can also access message history (date, time, source, destination).

• WeChat: basic data such as name, phone number, e-mail and IP address, but only for non-Chinese users.

• WhatsApp: the targeted person’s basic data, address book and contacts who have the targeted person in their address book; it is possible to collect message metadata in real time (“Pen Register”); message content can be retrieved via iCloud backups.

• Wickr: Date and time of account creation, types of terminal on which the application is installed, date of last connection, number of messages exchanged, external identifiers associated with the account (e-mail addresses, telephone numbers), avatar image, data linked to adding or deleting.

TL;DR Signal is the messaging system that provides the least information to investigators.

Metadata from a single picture can destroy your privacy
What someone can learn from your Image EXIF Metadata, and how to secure your photos ⌘ Read more

Dependabot relieves alert fatigue from npm devDependencies
A new alert rules engine for Dependabot leverages alert metadata to identify and auto-dismiss up to 15% of alerts as false positives. ⌘ Read more

**RT by @mind_booster: My new hobby: finding public domain images that Getty sells for $500, locating hi-rez scans of their original publications, cropping and cleaning them up, adding metadata, and uploading them to Wikimedia Commons.

First one: https://commons.wikimedia.org/wiki/File:Fig_6_Le_Telephone_by_T_De_Moncel_Paris_1878.png**
My new hobby: finding public domain images that Getty sells for $500, locating hi-rez scans of their original publications, cropping and cleaning them up, adding metadata, and uplo … ⌘ Read more

GitHub Security Lab audited DataHub: Here’s what they found
The GitHub Security Lab audited DataHub, an open source metadata platform, and discovered several vulnerabilities in the platform’s authentication and authorization modules. These vulnerabilities could have enabled an attacker to bypass authentication and gain access to sensitive data stored on the platform. ⌘ Read more

@movq@www.uninformativ.de
I would recommend a longer rotation, perhaps? The way I see it, you are proposing a monthly one. That can make metadata huge too. Maybe yearly, or every 6 months?

@mdom@domgoergen.com metadata is there now. I was one commit behind.

@sdk@codevoid.de Great! Though i don’t see any metadata on your feed?

New feature for txtnish: After setting add_metadata to 1, txtnish will, uhm, add metadata to your twtfile. Currently i only add followings, client and your gpg fingerprint. See my file for an example.

The workflow app on iOS is magic. I now have a button that asks me to select a picture, then converts it to png, resizes it, strips the metadata, scps it to my jumphost, scps it further to my gopher jail and into my paste directory, constructs the http proxy URL and opens it in safari. All without user-interaction. Now I can share my mobile life with you guys! Prepare for cat pictures!

@reednj@twtxt.xyz I think this would be the first time two clients implement the same #metadata format.

I’ll take another swing at #metadata for #twtxt. You can check my feed for an example. The headers aren’t important, only # key = value

Maybe we shouldn’t add time sensitive metadata. Maybe # following = https://domgoergen.com/twtxt/mdom.txt https://enotty.dk/twtxt.txt …

@kas@enotty.dk, @benaiah@benaiah.me Should metadata always be at the start of the file or can it be interspersed with tweets?

@mdom@domgoergen.com, @kas@enotty.dk re: metadata, I’m (obviously) in favor of my suggestion for metadata-in-comments, but I don’t think we should have comments in comments.

@kas@enotty.dk The amount of whitespace around the equal sign shouldn’t matter. Wouldn’t be a comment above the line not enough? <# nick = mdom # my nick> looks weird.

I would love to add metadata to the spec, but someone would have to hack it into twtxt #issue48 @buckket@buckket.org? :)

#txtnix and #roster now support the new metadata syntax ts#metadata. Now time will tell if somebody will use it.

This would be a good use case for metadata. @kas@enotty.dk could ask clients to refetch less, eg with /refetch 10m