# 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 55
# self = https://watcher.sour.is/conv/lrmnw3a
It’s pretty easy with jenny to use GPG to *sign* your feed (just do it in your publish_command), but of course, there’s no verification. 🤔 Should this be on the TODO list? Is it overkill? Nobody’s using it at the moment …
It’s pretty easy with jenny to use GPG to *sign* your feed (just do it in your publish_command), but of course, there’s no verification. 🤔 Should this be on the TODO list? Is it overkill? Nobody’s using it at the moment …
It’s pretty easy with jenny to use GPG to *sign* your feed (just do it in your publish_command), but of course, there’s no verification. 🤔 Should this be on the TODO list? Is it overkill? Nobody’s using it at the moment …
Signed this feed now. Let’s see what happens. 🤷
Signed this feed now. Let’s see what happens. 🤷
Signed this feed now. Let’s see what happens. 🤷
@movq it could be a handy thing to have. Of course, I could also sign with the publish_command and verify outside *jenny*, so, if it adds bloat and extra complexity I would say pass.
@movq it could be a handy thing to have. Of course, I could also sign with the publish_command and verify outside *jenny*, so, if it add bloat and extra complexity I would say pass.
@fastidious The key’s brand new, so maybe it takes a while for key servers to sync? (Dunno if they still do that.) I now pushed the key to keys.openpgp.org, just to be sure. 🤷
@fastidious The key’s brand new, so maybe it takes a while for key servers to sync? (Dunno if they still do that.) I now pushed the key to keys.openpgp.org, just to be sure. 🤷
@fastidious The key’s brand new, so maybe it takes a while for key servers to sync? (Dunno if they still do that.) I now pushed the key to keys.openpgp.org, just to be sure. 🤷
In theory, we could simply run gpg --verify ... on all feeds we retrieved and refuse to use the feed if that verification fails. So it shouldn’t be super hard to implement. I’m just not sure if it’s *worth it*. 🤔
In theory, we could simply run gpg --verify ... on all feeds we retrieved and refuse to use the feed if that verification fails. So it shouldn’t be super hard to implement. I’m just not sure if it’s *worth it*. 🤔
In theory, we could simply run gpg --verify ... on all feeds we retrieved and refuse to use the feed if that verification fails. So it shouldn’t be super hard to implement. I’m just not sure if it’s *worth it*. 🤔
… then again, a better solution might be: Allow the user to specify a validate_feed_command. That way, users can use anything they like, be it PGP or OpenBSD signify or whatever. So, feed signing would go into publish_command, feed validation into validate_feed_command. 🤔 And jenny wouldn’t ever have to deal with any of these crypto tools directly.
… then again, a better solution might be: Allow the user to specify a validate_feed_command. That way, users can use anything they like, be it PGP or OpenBSD signify or whatever. So, feed signing would go into publish_command, feed validation into validate_feed_command. 🤔 And jenny wouldn’t ever have to deal with any of these crypto tools directly.
… then again, a better solution might be: Allow the user to specify a validate_feed_command. That way, users can use anything they like, be it PGP or OpenBSD signify or whatever. So, feed signing would go into publish_command, feed validation into validate_feed_command. 🤔 And jenny wouldn’t ever have to deal with any of these crypto tools directly.
Either way, I’m not going to implement this right away. Feed Archival comes next.
Either way, I’m not going to implement this right away. Feed Archival comes next.
Either way, I’m not going to implement this right away. Feed Archival comes next.
@movq I'd like to take this a step further and define the notion of "private feeds" that are fully e2e encrypted and signed. I _think_ using keys.pub _could_ work nicely here.
@movq I'd like to take this a step further and define the notion of "private feeds" that are fully e2e encrypted and signed. I _think_ using keys.pub _could_ work nicely here.
@prologic So, private messages, essentially? I think that’s totally out of scope for “twtxt as a microblogging platform”, *but* it would be a required feature for “twtxt as a social network”. 🤔 Hmm … I guess I’ll have to play with keys.pub a bit (the weekend’s over, though, and my head is full of GnuPG garbage 🤣).
@prologic So, private messages, essentially? I think that’s totally out of scope for “twtxt as a microblogging platform”, *but* it would be a required feature for “twtxt as a social network”. 🤔 Hmm … I guess I’ll have to play with keys.pub a bit (the weekend’s over, though, and my head is full of GnuPG garbage 🤣).
@prologic So, private messages, essentially? I think that’s totally out of scope for “twtxt as a microblogging platform”, *but* it would be a required feature for “twtxt as a social network”. 🤔 Hmm … I guess I’ll have to play with keys.pub a bit (the weekend’s over, though, and my head is full of GnuPG garbage 🤣).
@movq I get plenty of warnings, that several lines are not parsable as twts, but that's to be expected.
@movq I _wouldn't_ necessarily think of it as "messaging" per se, but naturally it could be repurposed for that of course. @lyse ask me on #yarn.social on IRC what the use-case for this was. THe primary and most useful use-case is for "private social media". For example (_true story_); I was out with my family visiting the museum and we had a great time, took a few pics, etc. Naturally we wanted to share those moments with our extended family... What are your choices? Facebook, Twitter, TikTok, Instagram? Fuck no 🤣 All privacy eroding piles 💩
@movq I _wouldn't_ necessarily think of it as "messaging" per se, but naturally it could be repurposed for that of course. @lyse ask me on #yarn.social on IRC what the use-case for this was. THe primary and most useful use-case is for "private social media". For example (_true story_); I was out with my family visiting the museum and we had a great time, took a few pics, etc. Naturally we wanted to share those moments with our extended family... What are your choices? Facebook, Twitter, TikTok, Instagram? Fuck no 🤣 All privacy eroding piles 💩
@lyse I _believe_ also that yarnd's parser basically ignores the lines too.
@lyse I _believe_ also that yarnd's parser basically ignores the lines too.
@prologic Whenever I have some pictures I need to share with a few others, I just put them on a web page somewhere that isn't linked anywhere else and has <meta name="robots" content="noindex, ofollow"> on for good measure. Nobody I'm sharing it with has to sign up for anything, no entity outside my control is compressing the images, screwing with the metadata, or facially recognizing anyone, and you can just right click > save as if you want to download them.
I think it would be a much harder sell to get people on a weird social media service they've never heard of and encrypted feeds (as well as signed feeds) would make clients much more complex. I always have the anti-feature view, though. Maybe there's something I'm not seeing.
@mckinley Yes, introducing even more complexity is what I fear, too. For tech people it's just a hell lot easier to do exactly what you've described: put it somewhere and don't link it anywhere else. Maybe even remove it after a certain amount of time. That's what I've done ever since as well. However, in @prologic's vision non-techies could use encrypted feeds (if they overcome the hurdle you laid out nicely). I personally completely lack the usecase for them, too.
@lyse I see (and have) the use case, to be honest. Well, kind of. When *I* want to share stuff with my family, I do exactly what you guys said, but the problem is: When *another* family member wants to share data, they have no way of doing it. They usually end up doing horrible things like sharing stuff via Google Drive. Rarely do they post it in our Matrix room (probably because Element is a usability nightmare as well).
Some kind of “private social media”, where people could share their stuff, would be really nice.
Is twtxt the right platform/basis for this? I have no idea. 🤔 Right now, I’m very skeptical, but that might just be my German pessimism. 🤣
@lyse I see (and have) the use case, to be honest. Well, kind of. When *I* want to share stuff with my family, I do exactly what you guys said, but the problem is: When *another* family member wants to share data, they have no way of doing it. They usually end up doing horrible things like sharing stuff via Google Drive. Rarely do they post it in our Matrix room (probably because Element is a usability nightmare as well).
Some kind of “private social media”, where people could share their stuff, would be really nice.
Is twtxt the right platform/basis for this? I have no idea. 🤔 Right now, I’m very skeptical, but that might just be my German pessimism. 🤣
@lyse I see (and have) the use case, to be honest. Well, kind of. When *I* want to share stuff with my family, I do exactly what you guys said, but the problem is: When *another* family member wants to share data, they have no way of doing it. They usually end up doing horrible things like sharing stuff via Google Drive. Rarely do they post it in our Matrix room (probably because Element is a usability nightmare as well).
Some kind of “private social media”, where people could share their stuff, would be really nice.
Is twtxt the right platform/basis for this? I have no idea. 🤔 Right now, I’m very skeptical, but that might just be my German pessimism. 🤣
@movq
> Right now, I’m very skeptical, but that might just be my German pessimism.
I am also skeptical, but that might just be my Spanish cynicism. 🤣
@movq @fastidious Let me add another German conservativism to the table. I think a self-hosted file upload thing might be enough.
@movq If there were something like verify_command, how could we signal to _other_ feed consumers how to decrypt and/or verify a post? Also what about using TOFU here instead of a key sharing service?
Reading this thread, I see two things:
1. The example of image sharing can easily be solved by creating a private file hosting service that doesn't suck like @lyse said
2. We are getting close to the original purpose of Facebook here. A social media service based on identities rather than accounts and designed for people who know each other in meatspace to connect online. Facebook already does what we're talking about well; it has strong access controls to only show your content to people you choose. The only problem, of course, is that Facebook is evil.
"Social media" can take several forms.
- A "Twitter style" open microblogging system that allows people to discard and create identities with little consequences
- A "Facebook style" closed-off system that is more focused on real people interacting with each other instead of their online personas
- An "Internet forum style" system that focuses on discussion above all else
Twtxt and Yarn are designed as "Twitter style" systems. Perhaps twtxt can be adapted to a Facebook style system with that kind of access control and end-to-end encryption. Perhaps the result would be incredible. I am skeptical, however, of the idea that it would mix well with the current twtxt/Yarn ecosystem built on openness.
@mckinley I only used forums in the past, but I think your analysis is spot on!
@mckinley Yeah I think your right on the money there with:
> for people to get together online that know each other and meatspace
@mckinley Yeah I think your right on the money there with:
> for people to get together online that know each other and meatspace
@mckinley Hmm you do raise a good point re openness 🤔
@mckinley Hmm you do raise a good point re openness 🤔
Here’s another thing to consider:
Yarn.social has extended twtxt *a lot* in the past, but all these extensions were backward compatible. Yes, manually constructing threads is awkward, but not impossible. *Encrypted feeds*, on the other hand, are a whole new level. They are so profoundly incompatible with the original twtxt that I’m beginning to wonder: Maybe it’d be worth starting from scratch here? And in the process, solve some of the issues?
Dunno, just a thought.
Here’s another thing to consider:
Yarn.social has extended twtxt *a lot* in the past, but all these extensions were backward compatible. Yes, manually constructing threads is awkward, but not impossible. *Encrypted feeds*, on the other hand, are a whole new level. They are so profoundly incompatible with the original twtxt that I’m beginning to wonder: Maybe it’d be worth starting from scratch here? And in the process, solve some of the issues?
Dunno, just a thought.
Here’s another thing to consider:
Yarn.social has extended twtxt *a lot* in the past, but all these extensions were backward compatible. Yes, manually constructing threads is awkward, but not impossible. *Encrypted feeds*, on the other hand, are a whole new level. They are so profoundly incompatible with the original twtxt that I’m beginning to wonder: Maybe it’d be worth starting from scratch here? And in the process, solve some of the issues?
Dunno, just a thought.
@movq interesting proposition 🤔
@movq interesting proposition 🤔