Email or username:

Password:

Forgot your password?
10 posts total
Hrefna (DHC)

Draft of my (to-be) FEP for audience targeting and filtering is up at github.com/larpconnect/feather for those that are interested.

I haven't submitted as a FEP yet (and won't for a while), but that's the ultimate goal for it.

#FeatherPub #ActivityPub

Hrefna (DHC)

Note that the FEPs in this project are not "official" FEPs yet, they aren't submitted to the FEP process yet, that's just the eventual goal for them and so I've marked and labeled them as they should (hopefully) be labeled when further along.

But balancing between codeberg and GitHub and keeping everything up to date when trying to do development on a project that actively uses these was proving to be too complex, so I am working on them locally first.

Hrefna (DHC)

If you want an interesting demonstration of how a person (who doesn't particularly know Rust) solves a problem versus how the #Devin software solves a problem, these two PRs are worth comparing:

* Human: github.com/pvolok/mprocs/pull/ (Human Solution: HS)
* The solution Devin generated: github.com/pvolok/mprocs/pull/ (Devin Solution: DS)

There are a couple of things I want to highlight about these, because I think this is legitimately an interesting thing to look at.

1/

If you want an interesting demonstration of how a person (who doesn't particularly know Rust) solves a problem versus how the #Devin software solves a problem, these two PRs are worth comparing:

* Human: github.com/pvolok/mprocs/pull/ (Human Solution: HS)
* The solution Devin generated: github.com/pvolok/mprocs/pull/ (Devin Solution: DS)

Hrefna (DHC)

1) Note the differences in documentation. The DS is _very_ terse and mostly describes _what_ on a _very_ granular level, HS describes what and why on a much higher level, includes a screenshot of the expected result, and is mindful of backwards compatibility.

2) HS doesn't make extraneous changes. DS changes several things that are clearly stylistic choices in the original source, or where the original source is using a cleaner approach. DS modifies several of these to fit its "style"

2/

Dr. jonny phd

@hrefna super interesting, thx for writing out this comparison, actually genuinely useful to a very nooby language learner such as myself to see "bad version, good version" of a problem

Hrefna (DHC)

Okay, now that I'm less tired, a more salient point:

Opt-out is not "you haven't consented," opt-out is "we have a situation where there is generally consent and we are giving you the ability to _revoke_ that consent."

For instance, if I'm setting up a mastodon server, the fediverse has a _generally granted consent_ for me to do the things a normal mastodon server does, but they also provide a(n imperfect, more on that some other time) mechanism of consent _revocation_: blocking.

1/

Hrefna (DHC)

We also lack fine-grained controls around these things. We don't have a way to say "I never want my post to show up in Lemmy." We don't even have a way to say "I don't want my post to ever show up on the blocked server."

Your solution if you don't want to consent to these things is _limited federation_. Not authorized fetch, but actually allowlisting the servers you talk to.

Because we don't have a way to say/enforce these, your option if you aren't comfortable is to not participate.

2/

Johanna, CanCon variant

@hrefna perfect! That’s an excellent way to frame it.

Hrefna (DHC)

The fact that something is "valid" under #ActivityPub is really not relevant if there are literally no platforms out there that can federate with the "valid" AP protocol.

Just… we can discuss how part of the strength of AP as a protocol family is that it can be used for multiple independent protocols, but if your goal is to build a _fediverse_ app there just seems to be one frustration after the next in trying to get there.

Hrefna (DHC)

"Software isn't engineering, it is like <X>"

<describes something that is exactly like engineering>

Every. Single. Time.

Take an engineering cultures class and get back to me. -.-

Hrefna (DHC)

It can also be like other things, but it _is_ (or can be and often is) engineering.

I will fight those who say otherwise and I have citations to prove it.

It doesn't resemble modern structural engineering as it is practiced in the United States after 1950 or so. Agreed.

But engineering involves so so many more disciplines than structural engineering, and especially more than "structural engineering in the US post 1950."

Hrefna (DHC)

Fallacies that engineers* believe about documentation:

- Anyone will read more than a page of your documentation.
- Multiple adjacent paragraphs are easy to read.
- That people not reading your documentation is an issue of discoverability and not simply a fact of nature that people will not read documentation.
- You can get people to read documentation by writing more of it.
- An extension: that implementers who are relying on your docs will read your docs.

* It's me, I'm engineers.

Fallacies that engineers* believe about documentation:

- Anyone will read more than a page of your documentation.
- Multiple adjacent paragraphs are easy to read.
- That people not reading your documentation is an issue of discoverability and not simply a fact of nature that people will not read documentation.
- You can get people to read documentation by writing more of it.
- An extension: that implementers who are relying on your docs will read your docs.

Show previous comments
Philip Cardella

@hrefna at least if you have documentation you can get mad at the people who don't read it.

I worked with student engineers at Purdue on projects (exhibits) for my local science center that could take years and thus saw several changes to who was on the team working on it.

I cannot scream enough about the students who did NOT read their predecessors' documentation and then proceeded to make the exact same mistakes their predecessors made.

AND as the customer how rarely they talked to ME.

Philip Cardella

@hrefna read the documentation and talk to the customer. I mean, this is (or should be) engineering 101. Or at Purdue I think it was engineering 131, which my wife taught so I KNOW they were taught. Lol.

Philip Mallegol-Hansen

@hrefna @mariyadelano

IMO (Yes it’s a hot take, and honestly I should probably reconsider): If people don’t read the docs I prepared, it’s their problem if they don’t get something.

Hrefna (DHC)

Some notes on #golang, this is purely my personal opinion and not representative of my employer's take in any way.

When golang was first released there were several things that Rob Pike in particular seemed to think about it:

1. A replacement for C++ and Java for server systems

2. Good for large, scaled engineering teams. The sorts of teams with lots of moving parts

3. Effective for large amounts of data processing, especially the sort you do in web environments

go.dev/talks/2012/splash.artic

1/

Some notes on #golang, this is purely my personal opinion and not representative of my employer's take in any way.

When golang was first released there were several things that Rob Pike in particular seemed to think about it:

1. A replacement for C++ and Java for server systems

2. Good for large, scaled engineering teams. The sorts of teams with lots of moving parts

Hrefna (DHC)

They also made some assumptions in the kind of workflow they were trying to work with/encourage

1. They didn't like IDEs. They largely come from a group of devs and an era of devs who didn't (though I wouldn't say this was necessarily a common take at google at the time)

2. They _did_ like writing data structures. You feel very productive when writing data structures.

3. They were assuming something like a controlled monorepo for development

4. They wanted to optimize for training time

2/

Ben Evans

@hrefna A detailed & nuanced take that pretty closely matches what I observed of Go from over here in my mostly #Java / #JVM world.

Chris Laprun

@hrefna @kittylyst my main take, which I think matches yours, from my Go experience, is that Go is optimized for reading while Java has become optimized for writing

Hrefna (DHC)

The pattern of "you made an error, therefore we need to dig through all of your history on multiple platforms to prove that you are not one of us" is one of the most disturbing and destructive things I've seen on social media.

It also _definitely_ exists on Mastodon. I've seen it now multiple times.

But sure, tell me all about how bad quote tweets are.

Show previous comments
Amadi Lovelace

@hrefna I’ve had more than one friend who was hounded off of public social media because of harassment+ campaigns that were started by the tropical fruit ranchers, if you’re familiar, and I’ve been feeling this acutely. And yes, they were trans people.

Johannes Ernst

@hrefna of course the behavior has nothing to do with one social media app vs another. Saw a post today that derided somebody who couldn’t be any nicer if he tried as “xyz-lover” (where xyz=something objectionable). What is this all coming to? What happened to empathy, and gentleness?

Hrefna (DHC)

Actually effective strategies against #Meta to prevent an #EmbraceExtendExtinguish are difficult, but they start from asking "what will actually help here."

I maintain that preemptive #DefederateMeta is ineffective for this and that defederating from those who won't defederate from meta does more harm than good.

But what will help is thinking about the roadmap and getting there first. What will help is building a robust and thriving community around #ActivityPub and other fediverse protocols.

Hrefna (DHC)

Meta is looking to implement post importing. That's been a feature request since forever (see github.com/mastodon/mastodon/i and github.com/mastodon/mastodon/i ).

Secure messaging is another example.

These are things that if meta implements them and does even a halfway decent job then #meta controls the standard.

Want to prevent that?

Get there first or at least have a strong offering on how to do these things out of the gate. Let _us_ as a community control the standards that we use.

Meta is looking to implement post importing. That's been a feature request since forever (see github.com/mastodon/mastodon/i and github.com/mastodon/mastodon/i ).

Secure messaging is another example.

These are things that if meta implements them and does even a halfway decent job then #meta controls the standard.

Hrefna (DHC)

Overall I'm kind of just of the view that blocking #Meta's hypothetical server preemptively is just the most… performative, useless gesture

To annoy everyone who reads this for a moment, however:

It _does_ encompass what many leftists (and liberals) seem to think of as "taking action." A nice moral test. Easy to pontificate about. Feels good. Let's you talk in grandiose terms. Easy for an individual to do. Largely ineffective both short and long term.

I swear we are our own worst enemies.

Hrefna (DHC)

Point 1:

Meta's ability to scrape is not made worse by your defederating except in the most marginal terms.

Point 2:

If I were looking to #EmbraceExtendExtinguish I wouldn't be limited to a single server and I wouldn't be deterred by a few servers who are deciding not to talk to me.

You think Meta is going to shrug their shoulders if the instance of 10 people, foobar.example.baz, decides to not federate with them?

If _everyone_ defederated with them do you think they would just give up?

Go Up