The medium can be material or conceptual, permanent or fleating, truthful or fictional, of human, animal, or artificial origin.
Art is the reconveyance of human emotion or experience to another via some medium.
https://youtu.be/ZQNBVsLR5F0
> twtxt, as I believe it was originally intended, are short little status updates – that’s it.
So, basically a .plan file for finger. But, on the web. like a *web*finger. We have come full circle on this loop!
From my small experience in writing an event database, I am inclined to agree with this.
What if instead of signing each twt individually we generated a merkle tree using the twt hashes? Then a signature of the root hash. This would ensure the full stream of twts are intact with a minimal overhead. With the added bonus of helping clients identify missing twts when syncing/gossiping.
Have two endpoints. One as the webfinger to link profile details and avatar like you posted. And the signature for the merkleroot twt. And the other a pageable stream of twts. Or individual twts/merkle branch to incrementally access twt feeds.
Own your words. Don’t pour your limited keystrokes into a walled garden you don’t control or own. Twitter is not your blog.
i := fIndex(xs, 5.6)
Can also be
i := Index(xs, 5.6)
The compiler can infer the type automatically. Looks like you mention that later.
Also the infer is super smart.. You can define functions that take functions with generic types in the arguments. This can be useful for a generic value mapper for a repository
func Map[U,V any](rows []U, fn func(U) V) []V {
out := make([]V, len(rows))
for i := range rows { out = fn(rows[i]) }
return out
}
rows := []int{1,2,3}
out := Map(rows, func(v int) uint64 { return uint64(v) })
I am pretty sure the type parameters goes the other way with the type name first and constraint second.
func Foo[comparable T](xs T, s T) int
Should be
func Foo[T comparable](xs T, s T) intI am disappointed that a GUI app would not at least have screenshots.
https://www.openculture.com/2017/06/the-illustrated-guide-to-a-phd-12-simple-pictures-that-will-put-the-daunting-degree-into-perspective.html
Ratchet CLI now supports salty or ratchet comms!
Go has always been driven by usage data. Look at modules. There was need for having repeatable builds so various package tool chains were made and evolved into what we have today. Generics took time and seeing pain points where they would provide value. They weren't done just so it could be checked off on a box of features. Some languages seem to do that to the extreme.
Whenever changes are made to the language there are extensive searches across public modules for where the change might cause issues or could be improved with the change. The fs embed and strings.Cut come to mind.
I think its good that the language maintainers are using what metrics they have to guide where to focus time and energy. Some of the other languages could use it. So time and effort isn't wasted in maintaining something that has little impact.
The economics of the "spying" are to improve the product and ecosystem. Is it "spying" when a municipality uses water usage metrics in neighborhoods to forecast need of new water projects? Or is it to discover your shower habits for nefarious reasons?
go clean -modcache does. I think you can use another form that will remove just the deps for a specific module.
go clean -r
good luck to you!
I found this app that was created by the gopass author that does copy by default and has a tui or GUI mode https://github.com/cortex/ripasso
rachet-over-yarn mode enabled!
Though its a good mess of words you can throw around while saying "management supports this so X needs to get done"
!XO!1GcUL/ZbHj+CZnedB67ddd0tt3y1ppSLY7wbzMhraUeubCUH8LRT61pz6jPyOEa2wYYupwP7tu1cwR9mNN/k+No7PEw13kqBy6YvDU8jettw25Lkj3gZ+R4J1q6d0GWKKGx+OsYmJMPev7BL+5SCnt08qQYmgGAVhyhJZMkndIgk=!OX!
urn:example:apple:pear:plum:cherry
acct
---
subject: acct:me@sour.is
aliases:
- salty:me@sour.is
- yarn:xuu@ev.sour.is
- status:xuu@chaos.social
- mailto:me@sour.is
---
subject: salty:me@sour.is
aliases:
- acct:me@sour.is
links:
- rel: self
type: application/json+salty
href: https://ev.sour.is/inbox/01GAEMKXYJ4857JQP1MJGD61Z5
properties:
"http://salty.im/ns/nick": xuu
"http://salty.im/ns/display": Jon Lundy
"http://salty.im/ns/pubkey": kex140fwaena9t0mrgnjeare5zuknmmvl0vc7agqy5yr938vusxfh9ys34vd2p
---
subject: yarn:xuu@ev.sour.is
links:
- rel: https://txt.sour.is/user/xuu
properties:
"https://sour.is/rel/redirect": https://txt.sour.is/.well-known/webfinger?resource=acct%3Axuu%40txt.sour.is
---
subject: status:xuu@chaos.social
links:
- rel: http://joinmastodon.org#xuu%40chaos.social
properties:
"https://sour.is/rel/redirect": https://chaos.social/.well-known/webfinger?resource=acct%3Axuu%40chaos.social
---
subject: mailto:me@sour.is
...
I am kinda partial to using salty:acct:me@sour.is, yarn:acct:xuu@txt.sour.is, mailto:me@sour.is that could redirect to a specific service. and a parent account acct:me@sour.is that would reference them in some way. either in properties or aliases.
rel for salty account? since it is decentralized we dont have a set URL for machines to key off. so for example take the standard response from okta:
# http GET https://example.okta.com/.well-known/webfinger resource==acct:bob
{
"links": [
{
"href": "https://example.okta.com/sso/idps/OKTA?login_hint=bob#",
"properties": {
"okta:idp:type": "OKTA"
},
"rel": "http://openid.net/specs/connect/1.0/issuer",
"titles": {
"und": "example"
}
}
],
"subject": "acct:bob"
}
It gives one link that follows the OpenID login. So the details are specific to the subject
acct:bob.Mastodons response:
{
"subject": "acct:xuu@chaos.social",
"aliases": [
"https://chaos.social/@xuu",
"https://chaos.social/users/xuu"
],
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"type": "text/html",
"href": "https://chaos.social/@xuu"
},
{
"rel": "self",
"type": "application/activity+json",
"href": "https://chaos.social/users/xuu"
},
{
"rel": "http://ostatus.org/schema/1.0/subscribe"
}
]
}
it supplies a profile page and a
self which are both specific to that account.
my first thoughts about it were that a subject of acct:me@sour.is would have a listing of rel's for the different accounts that are related to me (ie. yarn, salty, twitter, mastodon, etc...)
but maybe my thinking is at the wrong level.. that each of those accounts would be on a subject level and the rels are describing different aspects of that account. so i would have salty:acct:xuu@sour.is, twitter:acct:xuu, mastodon:acct:xuu@chaos.social, yarn:acct:xuu@ev.sour.is and then i could have a main acct:me@sour.is that links them together as aliases.
I found okta will do something similar with its accounts to show as okta:acct:user@domain so maybe I am on to something?
https://connectorsupplier.com/usb-type-c-what-you-need-to-know/
some groups have created their own chips that have hidden keyloggers that can phone home over network connections.
https://shop.hak5.org/products/omg-cable
https://www.jamesshore.com/v2/projects/testing-without-mocks/testing-without-mocks
https://github.com/sour-is/ev/blob/main/app/peerfinder/http.go#L153
This is an upsert. So I pass a streamID which is like a globally unique id for the object. And then see how the type of the parameter in the function is used to infer the generic type. In the function it will create a new *Info and populate it from the datastore to pass to the function. The func will do its modifications and if it returns a nil error it will commit the changes.
The PA type contract ensures that the type fulfills the Aggregate interface and is a pointer to type at compile time.
https://github.com/sour-is/ev/blob/main/pkg/es/es.go#L315-L325
By adding the following to my config
i could go from
into 
deer walking through back yard
https://git.mills.io/yarnsocial/yarn/pulls/1095
func (p *Passwd) IsPreferred(hash string) bool {
\t_, algo := p.getAlgo(hash)
\tif algo != nil && algo == p.d {
\t\t// if the algorithm defines its own check for preference.
\t\tif ck, ok := algo.(interface{ IsPreferred(string) bool }); ok {
\t\t\treturn ck.IsPreferred(hash)
\t\t}
\t\treturn true
\t}
\treturn false
}
https://github.com/sour-is/go-passwd/blob/main/passwd.go#L62-L74
example: https://github.com/sour-is/go-passwd/blob/main/pkg/argon2/argon2.go#L104-L133
$ prefix!Well for this there is the option for a hash type to set itself as a fall through if a matching hash doesn't exist. This is good for legacy password types that don't follow the convention.
func (p *plainPasswd) ApplyPasswd(passwd *passwd.Passwd) {
\tpasswd.Register("plain", p)
\tpasswd.SetFallthrough(p)
}
https://github.com/sour-is/go-passwd/blob/main/passwd_test.go#L28-L31
func Example() {
\tpass := "my_pass"
\thash := "my_pass"
\tpwd := passwd.New(
\t\t&unix.MD5{}, // first is preferred type.
\t\t&plainPasswd{},
\t)
\t_, err := pwd.Passwd(pass, hash)
\tif err != nil {
\t\tfmt.Println("fail: ", err)
\t}
\t// Check if we want to update.
\tif !pwd.IsPreferred(hash) {
\t\tnewHash, err := pwd.Passwd(pass, "")
\t\tif err != nil {
\t\t\tfmt.Println("fail: ", err)
\t\t}
\t\tfmt.Println("new hash:", newHash)
\t}
\t// Output:
\t// new hash: $1$81ed91e1131a3a5a50d8a68e8ef85fa0
}
This shows how one would set a preferred hashing type and if the current version of ones password is not the preferred type updates it to enhance the security of the hashed password when someone logs in.
https://github.com/sour-is/go-passwd/blob/main/passwd_test.go#L33-L59
$name$ and then dispatch the hashing or checking to its specific format.
ZOMBIES
install "gomodot" puts you on the google first page. 
or August... or Jun-July... or April.. hard to say really.