#is it possibly a code or am i too far into this arg | Explore Tumblr posts and blogs

blindrapture · 4 years ago

Text

a union-mandated break post

(okay, let’s see if I can type this all over again after losing the post. gotta remember how it all went.)

Hey there, the few mutuals who Like all of my posts, the lurkers who occasionally make their presence known, the lurkers who I also hope are there, and all you folks who come across this post naturally before scrolling on (that’s fine too, please have a nice day! remember to take a deep breath and unclench!). I wanted to make a post giving a casual update.

Things have been going. You know how it is. Time proceeds onwards at a pace that is a crawl to some and fleeting to others, depending on relative perspective. The average of all these observations may be Objective Truth, a hazy mythical and abstract prospect which to this day no living human has ever known (due to the nature of perspective). We still try to know it for some reason, an endeavour which may be “a good thing” or “a condemnation of our species,” but that’s relative too. See above. Still, it is possible to take an approximation of what we figure this average to be and find ourselves (mis)balanced on a knife-edge in between all perspectives. This narrow path, the knife-edge between fast and slow, between good and bad, between ecstasy and despair, seems precarious at times, yet at other times is like a garden, wide and spacious enough to sit awhile. Our perspectives cover this garden from us with the shrubbery of Can’ts and Shouldn’ts, and the way to the garden is fraught with the misty cloud of Look-Like. And yet, ultimately, these shrubs and mists are but prismatic scenery colouring our time on this Earth, a perspective which is easy to see from within the garden. The Earth is brown and grey and immortal, though wearing an impermanent coat of blue and green. One day, we will slip out of our perspectives and return to the Earth, join her mounding’s mass, and that will be death.

So that’s the weather. Sometimes cold, sometimes mild, sometimes wet, sometimes dry, sometimes bothersome and sometimes the only backdrop I could ever want. I’ve been up to the usual, cycling between interests like a bat between haunts.

- The other day I got around to playing Smile For Me, an experience which took me about three hours to more-or-less complete 100%. Really cute game, I fell in love with all the characters, and the budding horror elements made me excited to see where it’d go.

- Currently I’m playing A Monster’s Expedition Through Puzzling Exhibitions, a game often cited in the same breath as Baba Is You and Stephen’s Sausage Roll. I think those two games are puzzle masterpieces, and A Monster’s Expedition is hitting me in the right spot. It frequently fills me with awe, which is impressive considering the game is just a long series of oblong block-pushing puzzles. It has scope, though, and it has the guts to hide that scope from you until you’re able to discover it for yourself. I’ve played for about 10 hours so far, beaten over 200 islands, and yet I feel I’m only getting further away from the end goal. Hard to describe. It’s a good game.

- When I’m done with that game, next I’ll be checking out Spelunky 2. I’ve wanted to try the original for a long time but never got around to it; I picked up the sequel. I know very little about the games (with a rough idea of what gameplay is like), and I intend to keep it that way for as long as I can. I like games that rely on discovery.

- Book-wise, I’m, y’know, reading Finnegans Wake as I fall asleep, occasionally inching through other books too, but my main reading focus at the moment is The Familiar. I went and picked up a new copy of Volume 5, and I found the Volume 3 I had kinda lost for a while, so now I have the full Season 1 again. And it’s been long enough since I read any of them that it’s finally time to reread them. As a unit this time. I am... so happy to be in their headspace. I’m currently in the second act of Volume 1, taking in a lot more details this time (and I do still remember a sense of where the whole plot goes), really cherishing the commitment to physicality and aesthetic. There’s not many authors out there like Danielewski. House of Leaves kickstarted my book obsession, y’know. And The Familiar is about as grand as a project can be. It’s supposed to be 27 volumes, each one 900 pages long, and the design of these books is goddamn sublime. The publisher only let him do the first 5 volumes, which is sad, but luckily those 5 volumes make up a “Season,” so they’re still a whole thing, a complete story arc for each of the nine protagonists, and plenty of secrets and details that give a good sense of the true scope. And did I mention the series is fucking scary? Profoundly so, each new volume weaving you deeper into its conspiratorial web of eldritch coincidences and patterns. The story is full of cats, immortal cats, God-cats. There’s a scientist who keeps a freaky magic orb and is known as Wizard. There’s an Armenian taxi driver who’s one of my favourite characters. And you can probably get all the volumes Used for fairly cheap on Amazon now. ........please, somebody join me in loving this series.

- Creative-wise, I’m working on music as always, putting notes next to each other until I get a result I can do something with. There is one piece that’s definitely done, a collaboration between Lindsay and I, but it’s going into Nine Is God so you won’t hear it just yet. Speaking of, that’s coming along. I haven’t even started making any codes or cool connections yet; I want to finish the... Core of this update first. Let’s be deceptive and call it the Main Blog. I have proven to myself that I definitely can do this; I keep stumbling on new mechanisms I can add, and I have a pretty vivid idea of what the whole thing will look like. It’s gonna be maybe a decent size for a Blog, all told, but it’s the form of the thing that mandates a lot of care. Luckily I have made Viceking’s Graab, so this isn’t the first time I’ve done something this mechanically ambitious. ...look, just. Of course I’m excited to Actually Talk about this thing, but like with the Graab, its nature requires me to keep it secret until players finally discover it for themselves. I like making that kind of thing, I want the sense of discovery, of climbing up a hill only to reach the summit and see an even bigger mountain looming over you that you hadn’t realized was there. Like Frog Fractions, or its sequel, even if you know there will be more than meets the eye you still get surprised and filled with delight. This concept fits neatly into an ARG format.

- Oh, also, I’m super excited for the Braid remake. It’s gonna have a comically thorough amount of developer commentary, and that’s all I want from this world. It’s even coming to Switch!

Media can be used as a tool to assist with the experience of life, and that is the way I want to approach things. I have spent time adapting myself to feel comfortable in these boring aesthetics (of understated puzzle games, thoughtful pretty books, blogs as art) because this means I am less susceptible to getting burned out during contemplation and self-examination. It may seem like a matter of taste, but taste is relative too; it’s not hard-wired, it can be adjusted, it does adjust all the time under the hood. ...I don’t know where to go with this one, other than that I should be careful not to condescend. I am not above anyone, I am confused too. I just.. like confusion and mazes, and I try to speak these aesthetics in an approximation of how I see others talk about theirs.

Right. I think that’s the bulk of it, that’s what I wanted to say today. I hope you are holding on, reader. It’s a wild and lonely world out there, and it’s our world; it’s yours just as much as it’s anyone else’s. You are important to it.

I leave you, mysteriously, with an old Genesis song. It’s called “Can-Utility and the Coastliners,” which is a silly way of saying it’s a song about the myth of King Canute. Sick of flatterers claiming he was equal to God, he went to the sea shore and said “If I truly am equal to God, then let the waves halt at my feet!” They didn’t. An astute demonstration, but it just prompted his flatterers to praise his ingenuity. “But he forced a smile, even though his hopes lay dashed where offerings fell.” I’m not really sure how the story ends. But it’s a wonderful song, starts off very folks-y but quickly takes a left turn down Mystery and Beauty. And it’s freaking Genesis.

See ya.

#rambles #at least they're not tag rambles this time #can't believe i managed to remember that whole ramble about relativity and objectivity and the garden in the middle #though amusingly i guess i really just remembered........ *an approximation* of it. :3

5 notes · View notes

programmingisterrible · 6 years ago

Text

What the hell is REST, Anyway?

Originating in a thesis, REST is an attempt to explain what makes the browser distinct from other networked applications.

You might be able to imagine a few reasons why: there's tabs, there's a back button too, but what makes the browser unique is that a browser can be used to check email, without knowing anything about POP3 or IMAP.

Although every piece of software inevitably grows to check email, the browser is unique in the ability to work with lots of different services without configuration—this is what REST is all about.

HTML only has links and forms, but it's enough to build incredibly complex applications. HTTP only has GET and POST, but that's enough to know when to cache or retry things, HTTP uses URLs, so it's easy to route messages to different places too.

Unlike almost every other networked application, the browser is remarkably interoperable. The thesis was an attempt to explain how that came to be, and called the resulting style REST.

REST is about having a way to describe services (HTML), to identify them (URLs), and to talk to them (HTTP), where you can cache, proxy, or reroute messages, and break up large or long requests into smaller interlinked ones too.

How REST does this isn't exactly clear.

The thesis breaks down the design of the web into a number of constraints—Client-Server, Stateless, Caching, Uniform Interface, Layering, and Code-on-Demand—but it is all too easy to follow them and end up with something that can't be used in a browser.

REST without a browser means little more than "I have no idea what I am doing, but I think it is better than what you are doing.", or worse "We made our API look like a database table, we don't know why". Instead of interoperable tools, we have arguments about PUT or POST, endless debates over how a URL should look, and somehow always end up with a CRUD API and absolutely no browsing.

There are some examples of browsers that don't use HTML, but many of these HTML replacements are for describing collections, and as a result most of the browsers resemble file browsing more than web browsing. It's not to say you need a back and a next button, but it should be possible for one program to work with a variety of services.

For an RPC service you might think about a curl like tool for sending requests to a service:

$ rpctl http://service/ describe MyService methods: ...., my_method $ rpctl http://service/ describe MyService.my_method arguments: name, age $ rpctl http://service/ call MyService.my_method --name="James" --age=31 Result: message: "Hello, James!"

You can also imagine a single command line tool for a databases that might resemble kubectl:

$ dbctl http://service/ list ModelName --where-age=23 $ dbctl http://service/ create ModelName --name=Sam --age=23 $ ...

Now imagine using the same command line tool for both, and using the same command line tool for every service—that's the point of REST. Almost.

$ apictl call MyService:my_method --arg=... $ apictl delete MyModel --where-arg=... $ apictl tail MyContainers:logs --where ... $ apictl help MyService

You could implement a command line tool like this without going through the hassle of reading a thesis. You could download a schema in advance, or load it at runtime, and use it to create requests and parse responses, but REST is quite a bit more than being able to reflect, or describe a service at runtime.

The REST constraints require using a common format for the contents of messages so that the command line tool doesn't need configuring, require sending the messages in a way that allows you to proxy, cache, or reroute them without fully understanding their contents.

REST is also a way to break apart long or large messages up into smaller ones linked together—something far more than just learning what commands can be sent at runtime, but allowing a response to explain how to fetch the next part in sequence.

To demonstrate, take an RPC service with a long running method call:

class MyService(Service): @rpc() def long_running_call(self, args: str) -> bool: id = third_party.start_process(args) while third_party.wait(id): pass return third_party.is_success(id)

When a response is too big, you have to break it down into smaller responses. When a method is slow, you have to break it down into one method to start the process, and another method to check if it's finished.

class MyService(Service): @rpc() def start_long_running_call(self, args: str) -> str: ... @rpc() def wait_for_long_running_call(self, key: str) -> bool: ...

In some frameworks you can use a streaming API instead, but replacing a procedure call with streaming involves adding heartbeat messages, timeouts, and recovery, so many developers opt for polling instead—breaking the single request into two, like the example above.

Both approaches require changing the client and the server code, and if another method needs breaking up you have to change all of the code again. REST offers a different approach.

We return a response that describes how to fetch another request, much like a HTTP redirect. You'd handle them In a client library much like an HTTP client handles redirects does, too.

def long_running_call(self, args: str) -> Result[bool]: key = third_party.start_process(args) return Future("MyService.wait_for_long_running_call", {"key":key}) def wait_for_long_running_call(self, key: str) -> Result[bool]: if not third_party.wait(key): return third_party.is_success(key) else: return Future("MyService.wait_for_long_running_call", {"key":key})

def fetch(request): response = make_api_call(request) while response.kind == 'Future': request = make_next_request(response.method_name, response.args) response = make_api_call(request)

For the more operations minded, imagine I call time.sleep() inside the client, and maybe imagine the Future response has a duration inside. The neat trick is that you can change the amount the client sleeps by changing the value returned by the server.

The real point is that by allowing a response to describe the next request in sequence, we've skipped over the problems of the other two approaches—we only need to implement the code once in the client.

When a different method needs breaking up, you can return a Future and get on with your life. In some ways it's as if you're returning a callback to the client, something the client knows how to run to produce a request. With Future objects, it's more like returning values for a template.

This approach works for breaking up a large response into smaller ones too, like iterating through a long list of results. Pagination often looks something like this in an RPC system:

cursor = rpc.open_cursor() output = [] while cursor: output.append(cursor.values) cursor = rpc.move_cursor(cursor.id)

Or something like this:

start = 0 output = [] while True: out = rpc.get_values(start, batch=30) output.append(out) start += len(out) if len(out) < 30: break

The first pagination example stores state on the server, and gives the client an Id to use in subsequent requests. The second pagination example stores state on the client, and constructs the correct request to make from the state. There's advantages and disadvantages—it's better to store the state on the client (so that the server does less work), but it involves manually threading state and a much harder API to use.

Like before, REST offers a third approach. Instead, the server can return a Cursor response (much like a Future) with a set of values and a request message to send (for the next chunk).

class ValueService(Service): @rpc() def get_values(self): return Cursor("ValueService.get_cursor", {"start":0, "batch":30}, []) @rpc def get_cursor(start, batch): ... return Cursor("ValueService.get_cursor", {"start":start, "batch":batch}, values)

The client can handle a Cursor response, building up a list:

cursor = rpc.get_values() output = [] while cursor: output.append(cursor.values) cursor = cursor.move_next()

It's somewhere between the two earlier examples of pagination—instead of managing the state on the server and sending back an identifier, or managing the state on the client and carefully constructing requests—the state is sent back and forth between them.

As a result, the server can change details between requests! If a Server wants to, it can return a Cursor with a smaller set of values, and the client will just make more requests to get all of them, but without having to track the state of every Cursor open on the service.

This idea of linking messages together isn't just limited to long polling or pagination—if you can describe services at runtime, why can't you return ones with some of the arguments filled in—a Service can contain state to pass into methods, too.

To demonstrate how, and why you might do this, imagine some worker that connects to a service, processes work, and uploads the results. The first attempt at server code might look like this:

class WorkerApi(Service): def register_worker(self, name: str) -> str ... def lock_queue(self, worker_id:str, queue_name: str) -> str: ... def take_from_queue(self, worker_id: str, queue_name, queue_lock: str): ... def upload_result(self, worker_id, queue_name, queue_lock, next, result): ... def unlock_queue(self, worker_id, queue_name, queue_lock): ... def exit_worker(self, worker_id): ...

Unfortunately, the client code looks much nastier:

worker_id = rpc.register_worker(my_name) lock = rpc.lock_queue(worker_id, queue_name) while True: next = rpc.take_from_queue(worker_id, queue_name, lock) if next: result = process(next) rpc.upload_result(worker_id, queue_name, lock, next, result) else: break rpc.unlock_queue(worker_id, queue_name, lock) rpc.exit_worker(worker_id)

Each method requires a handful of parameters, relating to the current session open with the service. They aren't strictly necessary—they do make debugging a system far easier—but problem of having to chain together requests might be a little familiar.

What we'd rather do is use some API where the state between requests is handled for us. The traditional way to achieve this is to build these wrappers by hand, creating special code on the client to assemble the responses.

With REST, we can define a Service that has methods like before, but also contains a little bit of state, and return it from other method calls:

class WorkerApi(Service): def register(self, worker_id): return Lease(worker_id) class Lease(Service): worker_id: str @rpc() def lock_queue(self, name): ... return Queue(self.worker_id, name, lock) @rpc() def expire(self): ... class Queue(Service): name: str lock: str worker_id: str @rpc() def get_task(self): return Task(.., name, lock, worker_id) @rpc() def unlock(self): ... class Task(Service) task_id: str worker_id: str @rpc() def upload(self, out): mark_done(self.task_id, self.actions, out)

Instead of one service, we now have four. Instead of returning identifiers to pass back in, we return a Service with those values filled in for us. As a result, the client code looks a lot nicer—you can even add new parameters in behind the scenes.

lease = rpc.register_worker(my_name) queue = lease.lock_queue(queue_name) while True: next = queue.take_next() if next: next.upload_result(process(next)) else: break queue.unlock() lease.expire()

Although the Future looked like a callback, returning a Service feels like returning an object. This is the power of self description—unlike reflection where you can specify in advance every request that can be made—each response has the opportunity to define a new parameterised request.

It's this navigation through several linked responses that distinguishes a regular command line tool from one that browses—and where REST gets its name: the passing back and forth of requests from server to client is where the 'state-transfer' part of REST comes from, and using a common Result or Cursor object is where the 'representational' comes from.

Although a RESTful system is more than just these combined—along with a reusable browser, you have reusable proxies too.

In the same way that messages describe things to the client, they describe things to any middleware between client and server: using GET, POST, and distinct URLs is what allows caches to work across services, and using a stateless protocol (HTTP) is what allows a proxy or load balancer to work so effortlessly.

The trick with REST is that despite HTTP being stateless, and despite HTTP being simple, you can build complex, stateful services by threading the state invisibly between smaller messages—transferring a representation of state back and forth between client and server.

Although the point of REST is to build a browser, the point is to use self-description and state-transfer to allow heavy amounts of interoperation—not just a reusable client, but reusable proxies, caches, or load balancers.

Going back to the constraints (Client-Server, Stateless, Caching, Uniform Interface, Layering and Code-on-Demand), you might be able to see how they things fit together to achieve these goals.

The first, Client-Server, feels a little obvious, but sets the background. A server waits for requests from a client, and issues responses.

The second, Stateless, is a little more confusing. If a HTTP proxy had to keep track of how requests link together, it would involve a lot more memory and processing. The point of the stateless constraint is that to a proxy, each request stands alone. The point is also that any stateful interactions should be handled by linking messages together.

Caching is the third constraint: labelling if a response can be cached (HTTP uses headers on the response), or if a request can be resent (using GET or POST). The fourth constraint, Uniform Interface, is the most difficult, so we'll cover it last. Layering is the fifth, and it roughly means "you can proxy it".

Code-on-demand is the final, optional, and most overlooked constraint, but it covers the use of Cursors, Futures, or parameterised Services—the idea that despite using a simple means to describe services or responses, the responses can define new requests to send. Code-on-demand takes that further, and imagines passing back code, rather than templates and values to assemble.

With the other constraints handled, it's time for uniform interface. Like stateless, this constraint is more about HTTP than it is about the system atop, and frequently misapplied. This is the reason why people keep making database APIs and calling them RESTful, but the constraint has nothing to do with CRUD.

The constraint is broken down into four ideas, and we'll take them one by one: self-descriptive messages, identification of resources, manipulation of resources through representations, hypermedia as the engine of application state.

Self-Description is at the heart of REST, and this sub-constraint fills in the gaps between the Layering, Caching, and Stateless constraints. Sort-of. It covers using 'GET' and 'POST' to indicate to a proxy how to handle things, and covers how responses indicate if they can be cached, too. It also means using a content-type header.

The next sub-constraint, identification, means using different URLs for different services. In the RPC examples above, it means having a common, standard way to address a service or method, as well as one with parameters.

This ties into the next sub-constraint, which is about using standard representations across services—this doesn't mean using special formats for every API request, but using the same underlying language to describe every response. In other words, the web works because everyone uses HTML.

Uniformity so far isn't too difficult: Use HTTP (self-description), URLs (identification) and HTML (manipulation through representations), but it's the last sub-constraint thats causes most of the headaches. Hypermedia as the engine of application state.

This is a fancy way of talking about how large or long requests can be broken up into interlinked messages, or how a number of smaller requests can be threaded together, passing the state from one to the next. Hypermedia referrs to using Cursor, Future, or Service objects, application state is the details passed around as hidden arguments, and being the 'engine' means using it to tie the whole system together.

Together they form the basis of the Representational State-Transfer Style. More than half of these constraints can be satisfied by just using HTTP, and the other half only really help when you're implementing a browser, but there are still a few more tricks that you can do with REST.

Although a RESTful system doesn't have to offer a database like interface, it can.

Along with Service or Cursor, you could imagine Model or Rows objects to return, but you should expect a little more from a RESTful system than just create, read, update and delete. With REST, you can do things like inlining: along with returning a request to make, a server can embed the result inside. A client can skip the network call and work directly on the inlined response. A server can even make this choice at runtime, opting to embed if the message is small enough.

Finally, with a RESTful system, you should be able to offer things in different encodings, depending on what the client asks for—even HTML. In other words, if your framework can do all of these things for you, offering a web interface isn't too much of a stretch. If you can build a reusable command line tool, generating a web interface isn't too difficult, and at least this time you don't have to implement a browser from scratch.

If you now find yourself understanding REST, I'm sorry. You're now cursed. Like a cross been the greek myths of Cassandra and Prometheus, you will be forced to explain the ideas over and over again to no avail. The terminology has been utterly destroyed to the point it has less meaning than 'Agile'.

Even so, the underlying ideas of interoperability, self-description, and interlinked requests are surprisingly useful—you can break up large or slow responses, you can to browse or even parameterise services, and you can do it in a way that lets you re-use tools across services too.

Ideally someone else will have done it for you, and like with a web browser, you don't really care how RESTful it is, but how useful it is. Your framework should handle almost all of this for you, and you shouldn't have to care about the details.

If anything, REST is about exposing just enough detail—Proxies and load-balancers only care about the URL and GET or POST. The underlying client libraries only have to handle something like HTML, rather than unique and special formats for every service.

REST is fundamentally about letting people use a service without having to know all the details ahead of time, which might be how we got into this mess in the first place.

19 notes · View notes

brilliantorinsane · 8 years ago

Text

Twitter ARG: A Sort of Summary

I’ve seen a lot of confusion here on Tumblr about what is supposedly going on in the twitter-verse. There’s a reason for that: it’s confusing. It’s vague. It relies on intuitions and moves in fits and starts. But it is also fascinating, compelling, and loads of fun. So for anyone who is interested I thought I’d give it a go, summarizing what is happening and what we think might happen. For starters:

The reason you’re hearing very little concrete information about twitter is: there is very little concrete information about twitter. It is all halls and mirrors. There have been (as far as I am aware) two major instances of people receiving DMs from the twitters: the first was the Dale Pike ‘reveal’ in which she ‘confessed’ and released her ‘script’; and the second prompted worriesconstantly’s announcement that we need to trend Norbury on March 21. But if it’s all so vague, why are putting any stock in it? Well, there are a few good reasons.

1. The show itself pointed us towards twitter in numerous ways.

2. If you’ve been following the ARG theories, you are doubtless aware of the speculation that the John and Sherlock twitters are BBC run. Evidence includes their posting of an original photo that seems like it could only have been taken from a window of the BBC building.

4. Our fellow tumblr-ers who are convinced something is going on. As far as I have seen, there tends to be a direct correlation between the amount of time someone has been digging through this twitter game and how convinced they are that something is happening. Sure, you could call that confirmation bias. Or, like I am inclined to do, you can see it as the collective consensus of those who have the most solid basis for reaching an informed conclusion.

3. The most compelling evidence is the intricacy of what is occurring. Like I’ve said, I’ve only been there two days, but it really is compelling. There’s a network of interconnecting accounts, interacting with each other and with us. Even those who don’t openly communicate display the most curious coincidences in timing. And it’s hard to conceive that they could be fellow-fans—there are too many oblique hints of ‘something coming,’ which would be cruel if they don’t actually know something. To me this feels like a game of ‘BBC or trolls’; and I’d be ridiculously impressed with any trolls who could pull this off, and somehow maintained this level of dedication and interest over such a span of time.

Very well, then. Here are the known players in this Twitter story:

1. The Sherlock and John accounts: These, of course, are the ones tumblr is most familiar with. For the most part, they are just telling an ongoing narrative about their happy existence as a couple—a remarkably frequent and high-quality narrative. However, they have had some meta discussions about stories, about ‘the game’ being a bit harsh but still worth playing . . . It is also worth noting that in their universe Rosie does exist, but the events of TFP apparently do not.

2. Contact_JM, i.e. an account that claims to be Moriarty: This one is also pretty well known around here. He tweets less frequently than the Sherlock and John, but still with impressive dedication. He has not infrequently dropped codes, puzzles, and cryptic clues. Other times he just rambles on in a thoroughly psychopathic-sounding manner.

3. Dale Pike/The Skull/ContactWSSH: Yes, this the Dale Pike who wrote the fics everyone went wild over, released a script they had written, then ‘confessed’ to being a fan and said goodbye. This one concerned me most at first, because I was genuinely concerned that we might be harping on a fan who just made a mistake and wanted to be left alone. The thing is: she didn’t leave. She is still posting fics which are no less meta and suggestive that her previous ones. And she is still using her Dale Pike twitter account—an account created solely for the purpose of . . . whatever it is she is doing. And while using that account she is still being just as openly cryptic and suggestive and interactive as ever—even to the point of resurrecting the old contactWSSH twitter and having a thoroughly mysterious conversation with them. Whoever she is, she has chosen to play this game; she hasn’t been forced into it. And what is she up to? Well, she is the queen of mixed messages. One moment kind and encouraging, the next insulting. Portraying herself as a fan and then claiming some mysteriously privileged status. Declaring she is finished only to begin again. Dropping cryptic hints, ranging from her fanfiction to an eminem music video which concludes with an innocent DVD being replaced by one labeled ‘explicit content.’ She is most likely one of the villains of this narrative.

4. Assorted: Besides these major players there are a few minor players who seem significant—@Bask_in_flies and @HarappaTiger have had brief, cryptic conversations with Contact_JM about executing some sort of plan. @eugenim portrays herself as sort of Eurus/Moriarty hybrid, and interacts like a cross between Contact_JM and Dale Pike: sometimes talking like a fan, sometimes like a psychopathic insider. Besides these, there are a few other potential players that people are keeping eyes on.

5. Creator twitters: there are a few of the Sherlock creators who periodically tweet things that are . . . suggestive, to say the least. Sometimes they are manifestly striking, other times they would passed unnoticed if it weren’t for uncanny timing: Gatiss and the Sherlock account both posting about moors around the same time, for example. The comments on their tweets can also be ripe with suggestion and ‘coincidence’.

Good. Now, finally: What all of this is hinting at:

I’m going to divide this section into two parts. First: What we know (as much as we know anything at this point):

1. The hints and the halls and mirrors cannot yet be assembled into a complete and coherent image. But they insistently hint at a secret episode, a false narrative, and something coming.

2. What has been seen on twitter strongly supports theories about a future fourth-wall break—both in the sense that what is going on in twitter is already breaking the fourth wall, and that it is hinting at some further, more undeniable break.

3. In this narrative, there are good guys and bad guys. Figuring out which is which seems to be part of the puzzle.

4. There are hints that this might be a ‘choose your own story’ ARG: obviously it would end in the release of The Lost Special no matter what we do, but we might have some say in how that happens and what role we play in its release.

5. Whatever is coming is still being only hinted at; it has not yet begun in earnest.

6. Maybe it’s a fluke, maybe it’s intentional, but this past week has felt different. More urgent—like something is coming. (Having just arrived I can’t testify to this one, obviously; but it seems to be the general consensus of those who have been involved long-term).

7. We are supposed to trend Norbury on March 21st—and this time, we will have help. (Okay, we don't technically know this. But again, worriesconstantly assures us that she has good reason to suspect this is the case on the basis of some dms. And seriously, what could she have to gain by making this up? Making people angry at her if nothing happens? There is always the possibility that this is another intentionally false lead from tptb; but worries constantly is certainly trustworthy, and it’s worth a try. Fortunately, #norbury has the added bonus of being worthwhile even if it doesn’t launch anything ARG related).

And finally: What we believe might be coming:

Well, okay, the actual speculations are far too numerous to actually list here. I’m just going to give my personal favorite theory about what might happen if/when the ARG kicks off and the fourth wall collapses for good. However, because this post is getting quite long and this isn’t really an essential part, I’m going to link to a separate post here for anyone who is interested.

In conclusion: What do we do with all of this?

Whatever you want, really. If you’d rather sit back and watch things unfold, go for it. (Although I’d still encourage participating in #norbury even if you are giving twitter theories a wide berth. That’s is a worthwhile project regardless of the ARG; something being set in motion by it would just be an added bonus!) But if you are aching for engagement, learning to navigate this twitter story will give you no end of entertainment and brain-teasers. So if you want to have a good time while potentially participating in making history, give it a look.

And remember, all of this endorsement is coming from someone who attached very little credibility to the ARG until getting on twitter just one day ago. If you’re intrigued, come and see for yourself. You would be most welcome!

@worriesconstantly

82 notes · View notes