# 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 14
# self = https://watcher.sour.is/conv/dhhickq
prologic
twtxt.net
View Thread
I've never liked the idea of having everything displayed all of the time for all of history.

And I still don't: Search and Bookmarks are better tools for this IMO.

From a technical perspective however, we will not introduce any CGO dependencies into yarnd -- It makes portability harder.

Also I hate SQL 😆
prologic
twtxt.net
View Thread
I've never liked the idea of having everything displayed all of the time for all of history.

And I still don't: Search and Bookmarks are better tools for this IMO.

From a technical perspective however, we will not introduce any CGO dependencies into yarnd -- It makes portability harder.

Also I hate SQL 😆
prologic
twtxt.net
View Thread
I've never liked the idea of having everything displayed all of the time for all of history.

And I still don't: Search and Bookmarks are better tools for this IMO.

From a technical perspective however, we will not introduce any CGO dependencies into yarnd -- It makes portability harder.

Also I hate SQL 😆
prologic
twtxt.net
View Thread
I've never liked the idea of having everything displayed all of the time for all of history.

And I still don't: Search and Bookmarks are better tools for this IMO.

From a technical perspective however, we will not introduce any CGO dependencies into yarnd -- It makes portability harder.

Also I hate SQL 😆
eldersnake
we.loveprivacy.club
View Thread
@prologic what do you dislike about SQL, just out of curiosity? Just personal preference or more architectural reason?
prologic
twtxt.net
View Thread
@eldersnake Several reasons:

- It's another language to learn (SQL)
- It adds another dependency to your system
- It's another failure mode (database blows up, scheme changes, indexs, etc)
- It increases security problems (now you have to worry about being SQL-safe)

And most of all, in my experience, it doesn't _actually_ solve any problems that a good key/value store can solve with good indexes and good data structures. I'm just no longer a fan, I used to use MySQL, SQLite, etc back in the day, these days, nope I wouldn't even go anywhere near a database (for my own projects) if I can help it -- It's just another thing that can fail, another operational overhead.
prologic
twtxt.net
View Thread
@eldersnake Several reasons:

- It's another language to learn (SQL)
- It adds another dependency to your system
- It's another failure mode (database blows up, scheme changes, indexs, etc)
- It increases security problems (now you have to worry about being SQL-safe)

And most of all, in my experience, it doesn't _actually_ solve any problems that a good key/value store can solve with good indexes and good data structures. I'm just no longer a fan, I used to use MySQL, SQLite, etc back in the day, these days, nope I wouldn't even go anywhere near a database (for my own projects) if I can help it -- It's just another thing that can fail, another operational overhead.
prologic
twtxt.net
View Thread
@eldersnake Several reasons:

- It's another language to learn (SQL)
- It adds another dependency to your system
- It's another failure mode (database blows up, scheme changes, indexs, etc)
- It increases security problems (now you have to worry about being SQL-safe)

And most of all, in my experience, it doesn't _actually_ solve any problems that a good key/value store can solve with good indexes and good data structures. I'm just no longer a fan, I used to use MySQL, SQLite, etc back in the day, these days, nope I wouldn't even go anywhere near a database (for my own projects) if I can help it -- It's just another thing that can fail, another operational overhead.
prologic
twtxt.net
View Thread
@eldersnake Several reasons:

- It's another language to learn (SQL)
- It adds another dependency to your system
- It's another failure mode (database blows up, scheme changes, indexs, etc)
- It increases security problems (now you have to worry about being SQL-safe)

And most of all, in my experience, it doesn't _actually_ solve any problems that a good key/value store can solve with good indexes and good data structures. I'm just no longer a fan, I used to use MySQL, SQLite, etc back in the day, these days, nope I wouldn't even go anywhere near a database (for my own projects) if I can help it -- It's just another thing that can fail, another operational overhead.
abucci
anthony.buc.ci
View Thread
@prologic yeah, I came to a similar place in my own work. SQL databases have their place, but a good key-value store is often the best choice.

I do love SQL as a language concept though. For a grad school project the group I was in wrote an interpreter for a SQL-like language that queried email, and it's so elegant.
prologic
twtxt.net
View Thread
@eldersnake Sorry, @lyse just pointed out to me on IRC at some ungodly hour this morning (_woke up for some reason_) that all my arguments are flawed 🤣 Regardless of my experiences and reasoning, I prefer to use bitcask for most things "dadtabase"(ish) and the "right data structures" for things I'm working with, be-it a key/value store, in-memory hashmap, write-ahead-log(s), indexes, etc. Perhaps I find it more comfortable and easier to use lower-level libraires to solve the same kinds of "data" needs.
prologic
twtxt.net
View Thread
@eldersnake Sorry, @lyse just pointed out to me on IRC at some ungodly hour this morning (_woke up for some reason_) that all my arguments are flawed 🤣 Regardless of my experiences and reasoning, I prefer to use bitcask for most things "dadtabase"(ish) and the "right data structures" for things I'm working with, be-it a key/value store, in-memory hashmap, write-ahead-log(s), indexes, etc. Perhaps I find it more comfortable and easier to use lower-level libraires to solve the same kinds of "data" needs.
prologic
twtxt.net
View Thread
@eldersnake Sorry, @lyse just pointed out to me on IRC at some ungodly hour this morning (_woke up for some reason_) that all my arguments are flawed 🤣 Regardless of my experiences and reasoning, I prefer to use bitcask for most things "dadtabase"(ish) and the "right data structures" for things I'm working with, be-it a key/value store, in-memory hashmap, write-ahead-log(s), indexes, etc. Perhaps I find it more comfortable and easier to use lower-level libraires to solve the same kinds of "data" needs.
prologic
twtxt.net
View Thread
@eldersnake Sorry, @lyse just pointed out to me on IRC at some ungodly hour this morning (_woke up for some reason_) that all my arguments are flawed 🤣 Regardless of my experiences and reasoning, I prefer to use bitcask for most things "dadtabase"(ish) and the "right data structures" for things I'm working with, be-it a key/value store, in-memory hashmap, write-ahead-log(s), indexes, etc. Perhaps I find it more comfortable and easier to use lower-level libraires to solve the same kinds of "data" needs.