Searching We.Love.Privacy.Club

Twts matching #follows.
Sort by: Newest, Oldest, Most Relevant

ARK FPV NDAA Compliant Flight Controller for UAV Applications with Advanced Sensors & Connectivity
The ARK FPV NDAA-compliant flight controller is compact and designed around the ARKV6X model, following a standard 30.5mm mounting pattern. It supports 3-12s battery input, providing a regulated 12V 2A output for video transmitters and payloads. The controller is compatible with PX4 Autopilot firmware (version 1.15+), pre-installed, and also supports … ⌘ Read more

⤋ Read More

I’m enjoying Wesley Chu’s Tao and Io series. Spies, action, ancient aliens. Some funny parts, some interesting world-building parts, some action-filled parts. I picked up The Fall of Io at random from a library a few weeks ago, and it turned out to be the last in a series of six (technically two series), so after finishing that I read the first and am partway through the second. Usually I try to read series in order, but this way is interesting. One thing I liked about The Fall of Io was that it it followed many points of view with somewhat conflicting interests, some more evil than others, and I felt sympathy for most of them. (I was kind of hoping it would be about Jupiter’s moon Io, but it wasn’t, but I’m satisfied with what I ended up with.) (2/4)

⤋ Read More

That’s very sad… Btw twtxt is more hardly to spam because of bad discovery. So you can only spam to your followers. Did you really want abandon best method of microblogging?

⤋ Read More

m-a-x-c creates Monero churn timing tool
m-a-x-c1 has created Monero Churn Timer 2 - a Python script that generates randomized wait times for XMR transactions and can potentially help users increase their privacy by scheduling churns:

The way it works is as follows: after receiving Monero, you would use the Monero Churn Timer to generate a random wait time. You would then set a reminder to “churn” (i.e., send that transaction to yourself at a new address) after the specified … ⌘ Read more

⤋ Read More

FWS-2290 is a Compact Desktop Network Appliance with Intel N97 for Security Solutions
The FWS-2290, recently launched by AAEON, is a desktop network appliance powered by Intel’s N-series processors, specifically the Intel Processor N97. Designed for UTM and VPN applications, it integrates features such as Intel Control-Flow Enforcement Technology, AES-NI, and Virtualization Technology for Directed I/O. This AAEON product is configured only with the following … ⌘ Read more

⤋ Read More

Beta 7 of iOS 18.1 & iPadOS 18.1 Available for Testing
Apple has issued the seventh beta versions of iOS 18.1 and iPadOS 18.1 for iPhone and iPad, respectively. Typically a MacOS Sequoia 15.1 beta soon follows as well. iOS 18.1, iPadOS 18.1, and macOS Sequoia 15.1 introduce the first Apple Intelligence AI features to compatible devices, and the emphasis should be on compatible devices because … [Read More](https://osxdaily.com/2024/10/14/beta-7-of-ios-18-1-ipados-18-1-availab … ⌘ Read more

⤋ Read More

RISC-V-Based KVM Solution in PCIe Form Factor with Low/High Profile Compatibility
The NanoKVM-PCIe is a recent solution from Sipeed, designed to simplify remote management of ATX PC cases and 2U servers. Built on the RISC-V architecture, it offers low power consumption and easy installation, with compatibility for both low-profile and high-profile PCIe brackets. This product follows the recent release of the Lichee NanoKVM Cube, an IP-KVM […] ⌘ Read more

⤋ Read More

It has twts cache which used if timeline is set to jew. Maybe i.should fork twet to make wishes like newlines (i see two squares), showing conversations, showing twts if not found in cache and parsing medata to configure url, nick and followers (currenly it duplicated in config and twtxt file)

⤋ Read More

Some more arguments for a local-based treading model over a content-based one:

  1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

  2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.

  3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don’t follow.

⤋ Read More

@lyse@lyse.isobeef.org I’d suggest making the whole content-type thing a SHOULD, to accommodate people just using some hosting service they don’t have much control over. (The same situation could make detecting followers hard, but IMO “please email me if you follow me” is still legit twtxt, even if inconvenient.)

⤋ Read More

@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