if a client sees someone in a yarn using a byte longer hash it can lengthen to match since it can assume that maybe the other client has a collision that it doesnt know about.
abcdef0123456789... any sub string of that hash after the first 6 will match. so abcdef, abcdef012, abcdef0123456 all match the same. on the case of a collision i think we decided on matching the newest since we archive off older threads anyway. the third rule was about growing the minimum hash size after some threshold of collisions were detected.
(delete: 5vbi2ea) .. would it delete someone elses twt?
i would rather it be a random value signed by a key. That way the key can change but the value stays the same.
> QUIC is expected to be a game-changer in improving web application performance. In this paper, we conduct a systematic examination of QUIC's performance over high-speed networks. We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. We observe this issue on lightweight data transfer clients and major web browsers (Chrome, Edge, Firefox, Opera), on different hosts (desktop, mobile), and over diverse networks (wired broadband, cellular). It affects not only file transfers, but also various applications such as video streaming (up to 9.8% video bitrate reduction) and web browsing. Through rigorous packet trace analysis and kernel- and user-space profiling, we identify the root cause to be high receiver-side processing overhead, in particular, excessive data packets and QUIC's user-space ACKs. We make concrete recommendations for mitigating the observed performance issues.
https://dl.acm.org/doi/10.1145/3589334.3645323
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: ...
Yikes! If only they had salty.im!
I never got the whole story of how it happened.
My wifes mom nearly got her account fully taken over by some hacker. They were able to get control and change password but I was able to get it recovered before they could get the phone number reset. They sent messages to all her contacts to send cash.
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.
This project is verrrry alpha. all the configuration is literally in the code.
https://github.com/timelinize/timelinize
•••••••
> On researching I see that HTTPS (tcp 443) traffic is continuing and originating from you NAT IP address 100.64.x.x
> This was further found to be originating from your firewall/router at 192.168.x.x (MAC D8:58:D7:x:x:x).
> This abuse is continuing and constitues a violation of \n Acceptable Use Policy and Terms of Service.
> Please take action to identify the source of the abuse and prevent it from continuing.
> Failure to stop the abuse may result in suspension or cancellation of service.
>
> Thank you,
> On researching I see that HTTPS (tcp 443) traffic is continuing and originating from you NAT IP address 100.64.x.x
> This was further found to be originating from your firewall/router at 192.168.x.x (MAC D8:58:D7:x:x:x).
> This abuse is continuing and constitues a violation of Senawave's Acceptable Use Policy and Terms of Service.
> Please take action to identify the source of the abuse and prevent it from continuing.
> Failure to stop the abuse may result in suspension or cancellation of service.
>
> Thank you,
> On researching I see that HTTPS (tcp 443) traffic is continuing and originating from you NAT IP address 100.64.x.x
> This was further found to be originating from your firewall/router at 192.168.x.x (MAC D8:58:D7:x:x:x).
> This abuse is continuing and constitues a violation of [ISP] Acceptable Use Policy and Terms of Service.
> Please take action to identify the source of the abuse and prevent it from continuing.
> Failure to stop the abuse may result in suspension or cancellation of service.
>
> Thank you,
go build could embed the values that go install does.
- at the function level you use cyclomatic complexity or how many branches internally and how much you need to keep in mind as it calls out to other functions.
- at a file/module level is a balance of the module doing too much against being so granular that you have cross dependency across modules. I have trouble with keeping things dry at this level because it can lead to parts being so abstract or generalized that it adds complexity.
- at a project level i suppose its a matter of how coupled things are across sub-modules.
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Oh.. And you are mentioning my dev instance here 😄
main
main
https://www.brennancenter.org/our-work/research-reports/citizens-united-explained?ref=foreverwars.ghost.io
caddy hash-password
https://dav.sour.is {
\ttls jon@xuu.cc
\tbasicauth /xuu {
\t\txuu $2a$...
\t}
\twebdav * {
\t\troot /var/www/dav
\t}
}
https://dav.sour.is {
tls jon@xuu.cc
basicauth /xuu {
xuu $2a$...
}
webdav * {
root /var/www/dav
}
}