They're in Section 6:
- Receiver should adopt UDP GRO. (Something about saving CPU processing UDP packets; I'm a but fuzzy about it.) And they have suggestions for making GRO more useful for QUIC.
- Some other receiver-side suggestions: "sending delayed QUICK ACKs"; "using recvmsg to read multiple UDF packets in a single system call".
- Use multiple threads when receiving large files.
body was a bit worn out today. switched it up to walk-run after about 5 miles because i have a daddy-daughter dance this afternoon and did not want to be too stiff. met another runner who actually only lives about a mile or less from me. maybe i will try to meet with him after my business trip next week.
#running
body was a bit worn out today. switched it up to walk-run after about 5 miles because i have a daddy-daughter dance this afternoon and did not want to be too stiff. met another runner who actually only lives about a mile or less from me. maybe i will try to meet with him after my business trip next week.
#running
body was a bit worn out today. switched it up to walk-run after about 5 miles because i have a daddy-daughter dance this afternoon and did not want to be too stiff. met another runner who actually only lives about a mile or less from me. maybe i will try to meet with him after my business trip next week.
#running
> > 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 the url tag 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 :-)
> > HTTPS is supposed to do \n 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 \n 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 the url tag 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 :-)
publish_command script!! THANK YOU! Now my website has TWO pages instead of just a boring one 😂 New: Log Page
publish_command script!! THANK YOU! Now my website has TWO pages instead of just a boring one 😂 New: Log Page
publish_command script!! THANK YOU! Now my website has TWO pages instead of just a boring one 😂 New: Log Page
/ME wondering if it's possible to use it locally just to read and manage my feed at first and then _maybe_ make it publicly accessible later.
/ME wondering if it's possible to use it locally just to read and manage my feed at first and then _maybe_ make it publicly accessible later.
/ME wondering if it's possible to use it locally just to read and manage my feed at first and then _maybe_ make it publicly accessible later.
Lyse's sunset
/https://baldo.cat/media/photos/IMG_1994.jpeg) #catsoftwtxt
#catsoftwtxt
#catsoftwtxt
Order placed!Now the wait starts. 😩😂
Welcome immigrants! ⌘ Read more****
Give me a couple of minutes, I'll give it a try myself 😉
Give me a couple of minutes, I'll give it a try myself 😉
Give me a couple of minutes, I'll give it a try myself 😉
> how would that work exactly?
To my limited knowledge, Keyoxide is an open source project offering different tools for verifying one's online persona(s). That's done by either A) creating an Ariande Profile using the web interface, a CLI. or B) Just using your GPG key. Either way, you add in Identity claims to your different profiles, links and whatnot, and finally advertise your profile ... Then there is a second set of Mobile/Web clients and CLI your correspondents can use to check your identity claims. I think of them like the front-ends of GPG Keyservers (which keyoxide leverages for verification when you opt for the GPG Key method), where you verify profiles using links, Key IDs and Fingerprints...
> Who maintains cox site? Is it centralized or decentralized can be relied upon?
- Maintainers? Definitely not me, but here's their Git stuff and OpenCollective page ...
- Both ASP and Keyoxide Webtools can be self-hosted. I don't see a central authority here... + As mentioned on their FAQ page the whole process can be done manually, so you don't have to relay on any one/thing if you don't want to, the whole thing is just another tool for convenience (with a bit of eye candy).
> Does that mean then that every user is required to have a cox side profile?
Nop. But it looks like a nice option to prove that I'm the same person to whom that may concern if I ever change my Twtxt URL, host/join a yarn pod or if I reach out on other platforms to someone I've met in her. Otherwise I'm just happy exchanging GPG keys or confirm the change IRL at a coffee shop or something. 😁
> how would that work exactly?
To my limited knowledge, Keyoxide is an open source project offering different tools for verifying one's online persona(s). That's done by either A) creating an Ariande Profile using the web interface, a CLI. or B) Just using your GPG key. Either way, you add in Identity claims to your different profiles, links and whatnot, and finally advertise your profile ... Then there is a second set of Mobile/Web clients and CLI your correspondents can use to check your identity claims. I think of them like the front-ends of GPG Keyservers (which keyoxide leverages for verification when you opt for the GPG Key method), where you verify profiles using links, Key IDs and Fingerprints...
> Who maintains cox site? Is it centralized or decentralized can be relied upon?
- Maintainers? Definitely not me, but here's their Git stuff and OpenCollective page ...
- Both ASP and Keyoxide Webtools can be self-hosted. I don't see a central authority here... + As mentioned on their FAQ page the whole process can be done manually, so you don't have to relay on any one/thing if you don't want to, the whole thing is just another tool for convenience (with a bit of eye candy).
> Does that mean then that every user is required to have a cox side profile?
Nop. But it looks like a nice option to prove that I'm the same person to whom that may concern if I ever change my Twtxt URL, host/join a yarn pod or if I reach out on other platforms to someone I've met in her. Otherwise I'm just happy exchanging GPG keys or confirm the change IRL at a coffee shop or something. 😁
> how would that work exactly?
To my limited knowledge, Keyoxide is an open source project offering different tools for verifying one's online persona(s). That's done by either A) creating an Ariande Profile using the web interface, a CLI. or B) Just using your GPG key. Either way, you add in Identity claims to your different profiles, links and whatnot, and finally advertise your profile ... Then there is a second set of Mobile/Web clients and CLI your correspondents can use to check your identity claims. I think of them like the front-ends of GPG Keyservers (which keyoxide leverages for verification when you opt for the GPG Key method), where you verify profiles using links, Key IDs and Fingerprints...
> Who maintains cox site? Is it centralized or decentralized can be relied upon?
- Maintainers? Definitely not me, but here's their Git stuff and OpenCollective page ...
- Both ASP and Keyoxide Webtools can be self-hosted. I don't see a central authority here... + As mentioned on their FAQ page the whole process can be done manually, so you don't have to relay on any one/thing if you don't want to, the whole thing is just another tool for convenience (with a bit of eye candy).
> Does that mean then that every user is required to have a cox side profile?
Nop. But it looks like a nice option to prove that I'm the same person to whom that may concern if I ever change my Twtxt URL, host/join a yarn pod or if I reach out on other platforms to someone I've met in her. Otherwise I'm just happy exchanging GPG keys or confirm the change IRL at a coffee shop or something. 😁
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂