# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 7
# self = https://watcher.sour.is/conv/2cdijnq
@mckinley I was reading your comments on A Design for a new Chat system and your most recent comment on a "base" spec and "extensions" resonated with me a lot.
In fact I'm actually not happy with this first draft at all, because I've mixed two things together here. Broker and Clients. I'd like to sit down and redo this so that the base spec is more similar to Twtxt (if that makes sense). Here's what an Inbox is, here's how you find one, here's how it behaves when you submit messages to it.
That sort of thing.
@mckinley I was reading your comments on A Design for a new Chat system and your most recent comment on a "base" spec and "extensions" resonated with me a lot.
In fact I'm actually not happy with this first draft at all, because I've mixed two things together here. Broker and Clients. I'd like to sit down and redo this so that the base spec is more similar to Twtxt (if that makes sense). Here's what an Inbox is, here's how you find one, here's how it behaves when you submit messages to it.
That sort of thing.
@prologic I'm glad you found my idea compelling. I agree that the broker and client specifications shouldn't be lumped together. I also think there should be a clear separation between client-to-server and server-to-server connections. The distinction between sending a message (POST http://montague.example/api/base/v1/post) and delivering a message (POST http://capulet.example/api/base/v1/inbox) should absolutely be enforced by the specification. I didn't see that last night, but it became clear after thinking about it.
@prologic I'm glad you found my idea compelling. I agree that the broker and client specifications shouldn't be lumped together. I also think there should be a clear separation between client-to-server and server-to-server connections. The distinction between sending a message (POST http://montague.example/api/v1/post) and delivering a message (POST http://capulet.example/api/v1/inbox) should absolutely be enforced by the specification. I didn't see that last night, but it became clear after thinking about it.
The server operator should be able to blacklist certain hosts as well as disable s2s connections entirely if they don't want federation. If a client can POST inboxes without a broker in the middle of the chain, it's too easy to automate and too hard to prevent spam.
Both really good points 👌 I shall try to rewrite this spec later this week when I'm not so bloody tired 😆
Both really good points 👌 I shall try to rewrite this spec later this week when I'm not so bloody tired 😆