raptros’s top 11 albums of 2013

well Aaron J Clarius (@graaaaaagh) challenged me to come up with my own top albums list for 2013. this turned out to be difficult, because 2013 had a lot of great metal releases, but i’ve come up with 11 albums that after having given them enough listening time to compare to the rest of the year, make it to the top. additionally, I’ve included a list of 13 runners-up – albums that didn’t make the cut, and albums that might have made the cut if i’d had more time to listen to them.

in no particular order, and without any explanation

  • Soilwork – The Living Infinite
  • Extol – Extol
  • Rivers of Nihil – The Conscious Seeds of Light
  • The Ocean – Pelagial
  • Rannoch – Between Two Worlds
  • Gorguts – Colored Sands
  • Disfiguring the Goddess – Deprive and Black Earth Child (clearly, the separate releases was just a troll – they came out on the same day, they form a double album)

  • Wormed – Exodromos
  • Pathology – Lords of Rephaim
  • Fallujah – Nomadic
  • Black Crown Initiate – Song of the Crippled Bull

below: 13 honorable mention, again without order or explanation (some of these would have had made the cut if i’d had more time to listen to them)

  • Last Chance to Reason – Level 3
  • Havok – Unnatural Selection
  • Living Sacrifice – Ghost Thief
  • The Monolith Deathcult – Tetragrammaton
  • Ovid’s Withering – Scryers of the Ibis
  • Byzantine – Byzantine
  • Tesseract – Altered States
  • In Vain – Ænigma
  • Exhale – When Worlds Collide
  • Circles – Infinitas
  • Uneven Structure – 8
  • Leprous – Coal
  • Persefone – Spiritual Migration

chatless (current status)

i’ve been working on the implementation of the chat system I talked about.

here’s the current spec document for requests that can be made to the user api. i’ve got tests and routing directives for three sections of that. (here’s how my implementation works: it processes the request – http verb, path, user auth – into an operation object, which it then sends to another actor (or actor system), which will do the database lookup and modification, and produce the response information, or raise an exception.)

as I’ve thought about this more, it’s become more clear to me that this can be extremely flexible. the crucial point will be designing the server-to-server api correctly – if I can pull that off, it’ll be capable of providing a single network with both large-scale public discussion servers and small private chat/info servers, with data from anywhere on the network available no matter where you connect (as long as your home server can be reached). hell, you could use a home server to set up topics that get fed by rss feed subscriptions and other info sources, and have those available on the go, encrypted and secured so other servers can’t read over your shoulder, while at the same time chatting in large public topics hosted by bigger servers. seamlessly.

plus, encrypted video chat on it still seems very doable.

simple, connectionless chat system – design draft

i intend to design a chat system. my goals:

  1. simple protocol spec
  2. no reliance on persistent connection state
  3. the protocol itself should not give an illusion of privacy wherever it is not possible to enable actual privacy (view permissions are for convenience not for privacy)
  4. decent, non-painful basic experience especially in terms of talking to people
  5. flexible enough to allow client implementations to implement all sorts of useful features (without requiring any modification or additional safeguarding in the server)

since web technologies exist, i will use them. the interface will therefore be a RESTful one – i think it’ll let me implement the intuitions about how this should work easily (and, even better, guide my intuitions to be in line whatever is already known to work).

a good REST interface, it is said, is based on collections of objects. here are some (key: bold means server fills field; plain means client provided, [bracketed] means client optional, (parens) means constraint or other info, <angled> means field takes sub-request, italics means only visible to a certain user):

  • users (who post topics); each has
    • an id (unique)
    • a handle  (unique)
    • an info object (an arbitrary json object within a network-set size limit)
    • an authentication thing (you know what i mean)
    • <followed users (list of user refs)>
    • <subscribed tags>
    • <allowed followers (list of user refs)>
    • allow followers automatically (default yes)
    • <blocked users (list of user refs – these ones cannot send requests to this user)>
    • <in topics (list of topic refs)>
  • topics (which contain messages); each topic has
    • an id (unique)
    • an original poster (a user ref)
    • a title (size limited string)
    • tags (set of strings)
    • public (boolean – yes: events will propagate out, anyone can join. no: only participants will see events, joins only by approval or by invitation)
    • <participants (a list of users who will see and post messages in the topic)>
    • <an info object (size limited json)>
    • <messages>; containing
      • an id (unique)
      • a timestamp
      • the poster (a user ref)
      • [a reply-to field (a message ref)]
      • a body object (size limited)
  • events (generated whenever a user interacts with a topic); each has
    • an id (unique)
    • a timestamp
    • an event type (what the user did to the topic)
    • a user ref
    • a topic ref
  • request (visible to both):
    • an id
    • a source user ref
    • a type (topic-invitation, permit-follow, permit-participate, etc)
    • a destination user ref
    • [a target topic ref]
    • [a message object (size limited)]
  • tags (topics can be tagged for searching); each has
    • a hash of the tag text
    • the tag text

so, where does this get us?
any request you make to these collections must be from the context of an authenticated user; however, you will not see anything at first – for access must be granted to you! so you follow some users – this sends permit-follow requests to those users, who either manually or automatically approve you (when you get approved, that user is added to your follow list, and you are added to that user’s allowed-followers list. then the request disappears.) you may also decide to follow tags.

then you get to query the events collection. events have a number of types – topic posted, message posted in topic, topic title changed, user joined topic, user left topic, etc. the collection can be filtered by type, tag, by user, by who you’re following, etc. it also can be queried in one of two ways – “before” and “after”.

  • “before”  takes an event id, or (by default “now”), and a count N >= 1(default 1), and returns the N tweets before (inclusive, and post-filtering) the event referenced (“now” means the most recent event available)
  • “after” takes an event id and a count N (default “all”), and returns the N tweets after (inclusive, post-filtering) the event referenced (“all” means return them all up to the most recent available event)

it is important to note that the event stream is always filtered first by whether or not an event is permitted to be shown to you. events from private topics will never enter your feed unless you are participating in those topics.

messages, requested from a topic, work by a similar principal (filtering on them operates on the body, though) – they too have before and after request types. in both collections, it is the after request mode that makes this work as a chat system. a working implementation must fulfil the request such that everything added after the item with the specified id was added will be returned.

now, a brief example of how client convention enables encrypted chat. your client obtains a public-key encryption keypair, and places the public key in your info object (with the index “publicKey”). someone wants to send a message only you can see, they look up your info object, get your public key, and encrypt the message before sending it to you. you want to send a message that everyone can verify is from you? you put text under the “text” index of your message object, then you hash it, decrypt it with your private key, and attach it to the message object on the “signature” index. when others in the topic receive it, they look up your public key, encrypt the signature, and compare it to the hash of the message text they receive. how about for group encrypted chat? the person setting up the topic creates a symmetric key, and a private topic. this OP then sends out invitations – each invitation contains the symmetric key encrypted with the public key of the invitation’s destination user. messages in the topic can then be encrypted and decrypted by all the invited users, using the same key. all that is needed is for clients to interpret the same fields the same way, (so they can automatically do the encryption and decryption for you. i suppose you could just manually move stuff to and from your encryption tools, but that’d be painful, I think.)

other things that need consideration:

  • server/service administration interfaces
    • how to add users
  • websocket for when-available streaming mode
  • more client conventions – for instance, implementation of encrypted voice or video chat
  • connecting servers to create networks
  • a name

my plan is to start working on an implementation tomorrow, once i figure out which of the frameworks for building REST apis in Scala to use.


today, I have to send a thing by mail. this is a very unusual case for me – even rarer than the occasions on which i have to send business reply mails. appropriate for such a momentous event, I have discovered that i do not have a single envelope suitable for this mailing anywhere here.

well, whatever, right? an envelope is just a piece of paper, cut out and folded, right? I have glue, scissors, and plenty of standard printing paper, i can just make my own! it’ll be easy!


business reply envelopes, designed to fit tri-folded letter papers, seem to all be of the size designated (on the wikipedia page) as #9 (or “windsor”). 3⅞ × 8⅞ (inches, all inches). standard letter paper sheet: 8.5 by 11. will that fit?

my initial answer was “hell no!”, and so I began looking for ways to combine two sheets to get things to work out. several crumpled attempts later, I threw it all off to the side in disgust, and pulled out a ruler, measured 3.875 inches from the bottom of the long edge, carefully made a few small marks, and then folded. the result? basically, the beginning of a pouch with the right height and enough paper overhanging to make a sealable flap.

the next step is obvious: measure in an inch and a 16th in from each of the short edges, and create neat folds there. open it all up and cut out the 4 corner rectangles. fold it together and then glue it (side flaps innermost, long thin flap outermost).

oh, so I put together a pdf with the lines you need. just print it out, cut out the corner pieces, and fold it up.

(in the process of attempting this myself, I discovered that all sorts of things had gone wrong with my printer setup. i’ve said it before, I’ll say it again: printers are not to be trusted.)

(updated to add: you will need a glue stick. i have 3. for some reason, the glue is purple.)

update 3: i just realized, if i’m going to the trouble of printing out envelopes, why not print them with the addresses on them? and furthermore, why not do it in a way that’s easily reused? and now i’m going to try to hack together some LaTeX.

update 4: ugh. this is a pain i haven’t gotten anywhere with it.

update 5: LaTeX isn’t at all the system to do this kind of layout work in – what the hell was I thinking?