it's interesting to see what scans show up in the logs:

2025-01-24 16:24:11 UTC 404 GET /.env 1.16ms
2025-01-24 16:24:11 UTC 404 GET /.env 563.87µs
2025-01-24 16:24:14 UTC 404 GET /.aws/credentials 601.43µs
2025-01-24 16:24:14 UTC 404 GET /.aws/credentials 498.43µs
2025-01-24 16:24:16 UTC 404 GET /.env.example 609.78µs
2025-01-24 16:24:16 UTC 404 GET /.env.example 544.13µs
2025-01-24 16:24:18 UTC 404 GET /.env.production 798.14µs
2025-01-24 16:24:19 UTC 404 GET /admin/.env 628.06µs
2025-01-24 16:24:23 UTC 404 GET /api/.env 906.66µs
2025-01-24 16:24:25 UTC 404 GET /app/.env 574.45µs
2025-01-24 16:24:27 UTC 404 GET /app_dev.php/_profiler/open?file=app/config/parameters.yml 537.69µs
2025-01-24 16:24:33 UTC 404 GET /app_dev.php/_profiler/phpinfo 841.8µs
2025-01-24 16:24:35 UTC 404 GET /backend/.env 513.92µs
2025-01-24 16:24:36 UTC 404 GET /core/.env 661.94µs
2025-01-24 16:24:38 UTC 404 GET /credentials 649.68µs
2025-01-24 16:24:40 UTC 404 GET /crm/.env 480.42µs
2025-01-24 16:24:43 UTC 404 GET /demo/.env 579.16µs
2025-01-24 16:24:49 UTC 404 GET /info/ 614.09µs
2025-01-24 16:24:51 UTC 404 GET /infos/ 705.33µs
2025-01-24 16:24:54 UTC 404 GET /pinfo.php 489.59µs
2025-01-24 16:24:58 UTC 404 GET /vendor/.env 780.1µs

this reminds me that i have to make responding to those requests much much slower...

#ktistec #security #todo

If you're running an instance of Ktistec and want to see what other ActivityPub instances are sending you, turn on JSON-LD processing debug logging.

1. Go the the /system URL.
2. Find the ktistec.json_ld setting.
3. Select "Debug" and save.

Ktistec will dump received activities to the log, after the activity has been parsed into JSON but before JSON-LD expansion.

2025-01-22 14:53:17 UTC 409 POST /actors/toddsundsted/inbox 4.29ms
2025-01-22T14:53:17.597172Z  DEBUG - ktistec.json_ld: {"@context" => ["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"],
"id" => "https://random.site/users/FooBar#delete", "type" => "Delete", "actor" => "https://random.site/users/FooBar", "object" => "https://random.site/users/FooBar", "to" => ["https://www.w3.org/ns/activitystreams#Public"], 
"signature" => {"type" => "RsaSignature2017", "creator" => "https://random.site/users/FooBar#main-key", "created" => "2025-01-22T14:52:40Z", "signatureValue" => "01234567890abcdefghijklmnopqrstuvwxyz=="}}

Answer to a FAQ:
The server returns HTTP status code 409 ("Conflict") if it has already received an activity.

#ktistec #fediverse #activitypub

Crystal is fast because methods are monomorphized at compile time. In simple terms, that means that at compile time, a polymorphic method is replaced by one or more type-specific instantiations of that method. The following polymorphic code...

def plus(x, y)
  x + y
end

...is effectively replaced by two methods—one that does integer addition if called with two integers, and one that does string concatenation if called with two strings.

This extends to inherited methods, which are implicitly also passed self. You can see this in action if you dump and inspect the symbols in a compiled program:

class FooBar
  def self.foo
    puts "#{self}.foo"
  end

  def bar
    puts "#{self}.bar"
  end
end

FooBar.foo
FooBar.new.bar

class Quux < FooBar
end

Quux.foo
Quux.new.bar

Dumping the symbols, you see multiple instantiations of the methods foo and bar:

...
_*FooBar#bar:Nil
_*FooBar::foo:Nil
_*FooBar@Object::to_s<String::Builder>:Nil
_*FooBar@Reference#to_s<String::Builder>:Nil
_*FooBar@Reference::new:FooBar
_*Quux@FooBar#bar:Nil
_*Quux@FooBar::foo:Nil
_*Quux@Object::to_s<String::Builder>:Nil
_*Quux@Reference#to_s<String::Builder>:Nil
_*Quux@Reference::new:Quux
...

The optimizer in release builds is pretty good at cleaning up the obvious duplication. But during my optimization work on Ktistec, I found that a lot of duplicate code shows up anyway.

Most pernicious are weighty methods that don't depend on class or instance state (don't make explicit or implicit reference to self). As I blogged about earlier, this commit replaced calls to the inherited method map on subclasses with calls to the method map defined on the base class and reduced the executable size by ~5.8%. The code was identical and the optimizer could remove the unused duplicates.

So, as a general rule, if you intend to use inheritance, put utility code that doesn't reference the state or the methods on the class or instance in an adjacent utility class—as I eventually did with this commit.

(The full thread starts here.)

#ktistec #crystallang #optimization

Ktistec release v2.4.5 rolls out the build time and executable size optimizations I've been blogging about here. It also fixes a few small bugs.

Fixed

• Handle @-mentions with hosts in new posts.
• Handle HEAD requests for pages with pretty URLs.
• Destroy session after running scripts.

Changed

• Delete old authenticated sessions.

I've started a branch full of query optimizations. My general rule—as highlighted in the server logs—is if a query takes longer than 50msec, it takes too long. It's time to address some problems...

#ktistec #fediverse #activitypub #crystallang

@jayvii i just discovered your introduction page. i liked it so much i copied the idea!

The prologue to this post, and other posts in the series, is here.

Investigating commit b65d292f was fruitful but not for obvious reasons.

Dumping the symbols (nm -j server) before and after the commit showed large number of new equality (==) methods. From the diff:

1765a1772
> _*ActivityPub::Activity::Accept#==<Translation>:Bool
1920a1928
> _*ActivityPub::Activity::Add#==<Translation>:Bool
2062a2071
> _*ActivityPub::Activity::Announce#==<Translation>:Bool
2237a2247
> _*ActivityPub::Activity::Block#==<Translation>:Bool
    ...

The use, in a controller action, of the new Translation model seemingly triggered their generation. What was going on?

A long time ago I implemented a MVC model framework in the style of ActiveRecord (2de4a4b3) and it included a method for testing for equality. Note the method signature.

# Returns true if all properties are equal.
#
def ==(other : self)
  {% begin %}
    {% vs = @type.instance_vars.select(&.annotation(Persistent)) %}
    if
      {% for v in vs %}
        self.{{v}} == other.{{v}} &&
      {% end %}
      self.id == other.id
      true
    else
      false
    end
  {% end %}
end

The Reference class—the default parent for classes—defines two base implementations of this method:  one that tests for identity (not equality), with the signature def ==(other : self), and another that returns false, with the signature def ==(other). When I implemented my method, my assumption was: redefine the former for model classes and let the latter take care of everything else. This assumption was incorrect.

In circumstances that I still don't completely understand, the compiler will generate calls to the latter (the method that just returned false) when it "should have" been calling the former, and comparisons failed when they should have succeeded. I "fixed this" with commit effeaa26 that removed the type restriction and explicitly handled the type check. Everything worked!

The problem is Crystal creates a version of this method for every possible model comparison, specialized by both self and other. Most of the time the type check fails and the method returns false. But the rest of the code is still present.

The fix (re)adds a method specialization that returns false and lets the compiler handle the type check.

# Returns `false`.
#
def ==(other)
  false
end

Because this method just returns a constant value, the compiler gets rid of the method call, as well.

Interestingly, this change reduced the size of the Ktistec server executable by 4.0% when building without the --release flag but only 0.2% when building with it, so optimization does a good job at cleaning this up even without the change. 

#ktistec #crystallang