Muerte negra por caricia
#catsoftwtxt
@quark@ferengi.one It looks like the part about traditional topics has been removed from that page. Here is an old version that mentions it: https://web.archive.org/web/20221211165458/https://dev.twtxt.net/doc/twtsubjectextension.html . Still, I don’t see any description of what is actually allowed between the parentheses. May be worth noting that twtxt.net is displaying the twts with the subject stripped, so some piece of code is recognizing it as a subject (or, at least, something to be removed).
@falsifian@www.falsifian.org based on Twt Subject Extension, your subject is invalid. You can have custom subjects, that is, not a valid hash, but you simply can’t put anything, and expect it to be treated as a TwtSubject, me thinks.
HTTPS is supposed to do [verification] anyway.
TLS provides verification that nobody is tampering with or snooping on your connection to a server. It doesn’t, for example, verify that a file downloaded from server A is from the same entity as the one from server B.
I was confused by this response for a while, but now I think I understand what you’re getting at. You are pointing out that with signed feeds, I can verify the authenticity of a feed without accessing the original server, whereas with HTTPS I can’t verify a feed unless I download it myself from the origin server. Is that right?
I.e. if the HTTPS origin server is online and I don’t mind taking the time and bandwidth to contact it, then perhaps signed feeds offer no advantage, but if the origin server might not be online, or I want to download a big archive of lots of feeds at once without contacting each server individually, then I need signed feeds.
feed locations [being] URLs gives some flexibility
It does give flexibility, but perhaps we should have made them URIs instead for even more flexibility. Then, you could use a tag URI,
urn:uuid:*, or a regular old URL if you wanted to. The spec seems to indicate that theurltag should be a working URL that clients can use to find a copy of the feed, optionally at multiple locations. I’m not very familiar with IP{F,N}S but if it ensures you own an identifier forever and that identifier points to a current copy of your feed, it could be a great way to fix it on an individual basis without breaking any specs :)
I’m also not very familiar with IPFS or IPNS.
I haven’t been following the other twts about signatures carefully. I just hope whatever you smart people come up with will be backwards-compatible so it still works if I’m too lazy to change how I publish my feed :-)
- Estoy malito 🤒 , ¿me haces una sopita de ratita?- 🍲🐭
#catsoftwtxt
@prologic@twtxt.net you should see This ! The devs were already trying to figure things out for TWTXT and Yarn.social 😃
I wonder if bento has slightly missed the key to being a total genius approach to host management. ok hear me out. each node periodically pulls configuration from a coordination node that hosts a binary cache. the admin may make changes and pre-build them maybe kick off an update task manually if they want, but the point is there’s an automated checkin. for my case, the device I have available for coordination isn’t really capable of hosting a binary cache for any of my other machines. the nix store for my dev machine is larger than the entire disk of the coordinator! and due to the yearly heat my best machine can’t be reliably powered on all the time. so i started thinking to myself, “self, what if instead of having a central coordinator we fetched configuration from a reliable git mirror (maybe git+torrent some day) and consume it as a flake. the source could even be swapped out using a flake registry (so you don’t even have to commit to self-hosting anything other than a json file). then managed hosts only have to be setup to consume the registry and the shared flake (which registers the update agent) and DONE?”
@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.
My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌
Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt seems to do or using the # url = metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:
Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.
See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu@txt.sour.is _) that the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.
- Si estiro de ahí… ¿caerá comida?-
#catsoftwtxt
-¿Vienes mucho por este cojín?-
#catsoftwtxt
-¡Fuera intruso! O te las verás con mis puños 👊 -
#catsoftwtxt
I just manually followed the steps at https://dev.twtxt.net/doc/twthashextension.html and got 6mdqxrq. I wonder what happened. Did @cuaxolo@sunshinegardens.org edit the twt in some subtle way after twtxt.net downloaded it? I couldn’t spot a diff, other than ‘ appearing as ’ on yarn.social, which I assume is a transformation done by twtxt.net.
@prologic@twtxt.net They are but then again Apple’s is doing things Apple’s way 😆 Hint: punishing devs and users for using alternative stores.
-De mayor voy a ser gatonauta-
#catsoftwtxt
Gato encajonado
#catsoftwtxt
oh dang. i think thats the go path not the github path.. missing the branch name. here is the pkg one: https://pkg.go.dev/github.com/quic-go/quic-go/http3
from my understanding.. i don’t know how the multiplexing works when its being proxied through another server. I know go has support for it if you call it out directly. https://pkg.go.dev/golang.org/x/net/http2
¡Baldo ha sido castrado! Está en proceso de recuperación ❤️🩹
#catsoftwtxt
Solo en la noche
#catsoftwtxt
Oculto
#catsoftwtxt
minibase bootstrap iso first look is up on the gits https://git.ix.cyb.red/IX/minibase/src/branch/main/dev/bootstrap #nix #lix
⭐️⭐️⭐️⭐️⭐️ El michi llegó en perfectas condiciones y bien protegido
#catsoftwtxt
¡Caja asegurada! No hay 🐭
#catsoftwtxt
Habrá que ir pensando en cambiarle la casita
#catsoftwtxt
Muerte con caricias 2: ahora vamos de negro
#catsoftwtxt
Jugando a ser mayor
#catsoftwtxt
Aprendiendo de los mayores
#catsoftwtxt
(I don’t really trust Android, though, and I suspect that apps can still install background services that are always active. Pure speculation and paranoid on my part, but still.)
Which is fair, but I would say the GrapheneOS devs in particular are also quite paranoid about this stuff and go to great pains to make sure this stuff can be controlled by the user.
España!!
#catsoftwtxt
Gato enmarcado
#catsoftwtxt
Crece por horas
#catsoftwtxt
- ¡FUERA DE MI CASTILLO! -
#catsoftwtxt
Yeah, though sometimes the most clever devs aren’t always the best to deal with on a personal level. I seem to remember the (former?) lead dev on GrapheneOS (IIRC) was an ass hat and threw tantrums at the smallest things and would get stalkery and weird if someone criticised him, but he’s undeniably a brilliant coder and problem solver. Some people need to be more self aware of how their efforts might be harmed with their behaviour though.
Gato en su funda
#catsoftwtxt