Searching txt.sour.is

Twts matching #Twt
Sort by: Newest, Oldest, Most Relevant
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

**(#rjapt4a) I think it uses the first # url too. See here and here – @xuu@xuu Can you confirm this to be the case? 🙏 GetN("url", ...** I _think_ it uses the first# urltoo. See [here](https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/ast.go#L1062-L1074) and [here](https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/lextwt.go#L88-L95) – [@xuu _@txt.sour.is_](https://twtxt.net/external?uri=https://txt.sour.is/user/xuu/twtxt.txt&nick=xuu) Can you confirm this to be the case? 🙏GetN(“url”, 0)will return the fir ... ⌘ [Read more](https://twtxt.net/twt/5ieybsq)

⤋ Read More
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

(#u2uoxea) @movq you are absolutely right! And it did happen once more in the past as well. The difficulty about this particular new behavior th …
@movq @www.uninformativ.de you are absolutely right! And it did happen once more in the past as well. The difficulty about this particular new behavior though is that I’ve also had to blacklist it and remove it from the search engine and crawler for obvious reasons. ⌘ Read more

⤋ Read More
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

My very strong opinion on the use of Twtxt is if you intend to use it, you should be prepared to let people pull your feed or at least check it …
My very strong opinion on the use of Twtxt is if you intend to use it, you should be prepared to let people pull your feed or at least check it and regular rentals.

Otherwise get out and go use something that’s either a distributed (Mastodon, AT, etc) or centralized (Facebook, X, etc) network. ⌘ Read more

⤋ Read More
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

(#u2uoxea) @bender@bender Agreed. I just find it an abhorrent that certain folks just don’t even bother to spend the few mins that it takes t …
@bender Agreed. I just find it an abhorrent that certain folks just don’t even bother to spend the few mins that it takes to reach out. Compares to hours of their time to cause havoc and mischief. Seriously wut da fuq?! 🤦‍♂️ ⌘ Read more

⤋ Read More
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

After the behaviour of a clearly very angry feed author over the past few days, I’m very tempted to give up on Twtxt and allow it to go back to …
After the behaviour of a clearly very angry feed author over the past few days, I’m very tempted to give up on Twtxt and allow it to go back to being dead. What really is the point of building and supporting a way to exchange little pieces of text with one another in a completely decentralised way, if you’re just going to keep humping up against such hostility? I don’t know why I do this any … ⌘ Read more

⤋ Read More
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

(#rjapt4a) @movq I’m assuming jenny is doing some kind of validation and verifying if that Twt really does exist on the feed uri? 🤔 But the …
@movq @www.uninformativ.de I’m assuming jenny is doing some kind of validation and verifying if that Twt really does exist on the feed uri? 🤔 But the hash is all kinds of wrong now because @gallowsgryph for whatever reason decided it might be a good idea to have a 2nd # url that doesn’t actually point to t … ⌘ Read more

⤋ Read More
prologic-twtxt-atom-feed
feeds.twtxt.net
 (1y ago)

(#uuuctoa) > The text parameters are percent-decoded before matching. Dash (-), ampersand (&), and comma (,) characters in text parameters are p …

The text parameters are percent-decoded before matching. Dash (-), ampersand (&), and comma (,) characters in text parameters are percent-encoded to avoid being interpreted as part of the text directive syntax. ⌘ Read more

⤋ Read More
xuu
txt.sour.is
 (1y ago)
↳ In-reply-to » @prologic I wanted to wait for things to settle down. It’s still unclear to me in which direction we’re going – and if that new/different stuff is even possible to implement in jenny. That said, I’ve been really busy with private stuff these last few days, I’ve lost track of most of what you’re discussing. 🥴

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

  1. If yarn has one use that. (Maybe do collision check?)
  2. Make hash of twt raw no truncation.
  3. Check local cache for shortest without collision
    • in SQL: select len(subject) where head_full_hash like subject || '%'

Threading:

  1. Get full hash of head twt
  2. Search for twts
    • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

⤋ Read More
xuu
dev.txt.sour.is
 (1y ago)
↳ In-reply-to » @prologic I wanted to wait for things to settle down. It’s still unclear to me in which direction we’re going – and if that new/different stuff is even possible to implement in jenny. That said, I’ve been really busy with private stuff these last few days, I’ve lost track of most of what you’re discussing. 🥴

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

  1. If yarn has one use that. (Maybe do collision check?)
  2. Make hash of twt raw no truncation.
  3. Check local cache for shortest without collision
    • in SQL: select len(subject) where head_full_hash like subject || '%'

Threading:

  1. Get full hash of head twt
  2. Search for twts
    • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

⤋ Read More
sorenpeter
darch.dk
 (1y ago)
↳ In-reply-to » There we go!

@prologic@twtxt.net Regarding the new way of generating twt-hashes, to me it makes more sense to use tabs as separator instead of spaces, since the you can just copy/past a line directly from a twtxt-file that already go a tab between timestamp and message. But tabs might be hard to “type” when you are in a terminal, since it will activate autocomplete…🤔

Another thing, it seems that you sugget we only use the domain in the hash-creation and not the full path to the twtxt.txt

$ echo -e "https://example.com 2024-09-29T13:30:00Z Hello World!" | sha256sum - | awk '{ print $1 }' | base64 | head -c 12

⤋ Read More
aelaraji
aelaraji.com
 (1y ago)
↳ In-reply-to » Only with dovecot xD. For mail im use android native mail client and not mutt. And jenny display some errors with found some files and /tmp dir (android dont have /tmp)

I believe I’d missed an f:

~/src/jenny $ git diff
diff --git a/jenny b/jenny
index ada8da2..8ae9a06 100755
--- a/jenny
+++ b/jenny
@@ -1194,7 +1194,7 @@ if __name__ == '__main__':
     if args.edit:
	edit_twt_file(app)
     elif args.fetch:
-        with DirectoryLock(f'/tmp/jenny-{getuser()}.run'):
+        with DirectoryLock(expanduser(f'~/tmp/jenny-{getuser()}.run')):
             retrieve_all(app)
     elif args.last_seen:
	 print('Feeds last seen at (times are local time), oldest first:')

⤋ Read More
aelaraji
aelaraji.com
 (1y ago)
↳ In-reply-to » Only with dovecot xD. For mail im use android native mail client and not mutt. And jenny display some errors with found some files and /tmp dir (android dont have /tmp)

@doesnm@doesnm.p.psf.lt I’ve just given it a try on android/termux and got it to work, I can’t promise it won’t break something else (because i definitely don’t know what I’m doing) but here’s what I broke 😅:

~/src/jenny $ git diff
diff --git a/jenny b/jenny
index ada8da2..8ae9a06 100755
--- a/jenny
+++ b/jenny
@@ -1194,7 +1194,7 @@ if __name__ == '__main__':
     if args.edit:
	edit_twt_file(app)
     elif args.fetch:
-        with DirectoryLock(f'/tmp/jenny-{getuser()}.run'):
+        with DirectoryLock(expanduser('~/tmp/jenny-{getuser()}.run')):
             retrieve_all(app)
     elif args.last_seen:
	 print('Feeds last seen at (times are local time), oldest first:')

and of course make sure you mkdir ~/tmp

⤋ Read More
doesnm
doesnm.p.psf.lt
 (1y ago)
↳ In-reply-to » @doesnm twt probably isn't the best client I'm afraid. It doesn't really cache twts by their key (hash) to display threads properly. Jenny however does 👌

It has twts cache which used if timeline is set to jew. Maybe i.should fork twet to make wishes like newlines (i see two squares), showing conversations, showing twts if not found in cache and parsing medata to configure url, nick and followers (currenly it duplicated in config and twtxt file)

⤋ Read More
prologic
twtxt.net
 (1y ago)

👋 Thanks for joining us on our Sept monthly Yarn.social meetup today y’all 🙇‍♂️ We had @david@collantes.us @sorenpeter@darch.dk @doesnm@doesnm.p.psf.lt @falsifian@www.falsifian.org and @xuu@txt.sour.is 💪 Nice turn out! (not all at once of course, as we normally run this over 4 hours as we span many time zones!)

Things we talked about:

  • Decentralised vs. Distributed
  • Use of SHA256 for Twt Hash(es)
  • We solved Edits! 🥳
  • UUID(s) probably won’t work! (susceptible to sppofing)
  • Helped @sorenpeter@darch.dk write some PHP to process/parse User-Agent and service his feed via a custom PHP script 😅
  • @falsifian@www.falsifian.org introduced himself 👌
  • Talked about Merkle Trees 🌳

Did I miss anything? 🤔

⤋ Read More
prologic
twtxt.net
 (1y ago)
↳ In-reply-to » Something @anth said on ITC

We:

  • Drop # url= from the spec.
  • We don’t adopt # uuid = – Something @anth@a.9srv.net also mentioned (see below)

We instead use the @nick@domain to identify your feed in the first place and use that as the identify when calculating Twt hashes <id> + <timestamp> + <content>. Now in an ideal world I also agree, use WebFinger for this and expect that for the most part you’ll be doing a WebFinger lookup of @user@domain to fetch someone’s feed in the first place.

The only problem with WebFinger is should this be mandated or a recommendation?

⤋ Read More
lyse
lyse.isobeef.org
 (1y ago)
↳ In-reply-to » This is only first draft quality, but I made some notes on the #twtxt v2 proposal. http://a.9srv.net/b/2024-09-25

Good writeup, @anth@a.9srv.net! I agree to most of your points.

3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.

3.4 Multi-Line Twts: What exactly do you think are bad things with multi-lines?

4.1 Hash Generation: I do like the idea with with a new uuid metadata field! Any thoughts on two feeds selecting the same UUID for whatever reason? Well, the same could happen today with url.

5.1 Reply to last & 5.2 More work to backtrack: I do not understand anything you’re saying. Can you rephrase that?

8.1 Metadata should be collected up front: I generally agree, but if the uuid metadata field were a feed URL and no real UUID, there should be probably an exception to change the feed URL mid-file after relocation.

⤋ Read More
prologic
twtxt.net
 (1y ago)
↳ In-reply-to » Some more arguments for a local-based treading model over a content-based one:

And finally the legibility of feeds when viewing them in their raw form are worsened as you go from a Twt Subject of (#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).

⤋ Read More
prologic
twtxt.net
 (1y ago)
↳ In-reply-to » Some more arguments for a local-based treading model over a content-based one:

There is also a ~5x increase cost in memory utilization for any implementations or implementors that use or wish to use in-memory storage (yarnd does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (on the average case).

⤋ Read More
prologic
twtxt.net
 (1y ago)
↳ In-reply-to » Some more arguments for a local-based treading model over a content-based one:

So really your argument is just that switching to a location-based addressing “just makes sense”. Why? Without concrete pros/cons of each approach this isn’t really a strong argument I’m afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.

I also don’t really buy the argument of simplicity either personally, because I don’t technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> – The “effort” is the same. If we’re going to argue that SHA256 or cryptographic hashes are “too complicated” then I’m not really sure how to support that argument.

⤋ Read More
sorenpeter
darch.dk
 (1y ago)

Some more arguments for a local-based treading model over a content-based one:

  1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

  2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.

  3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don’t follow.

⤋ Read More
falsifian
www.falsifian.org
 (1y ago)
↳ In-reply-to » @prologic Thanks for writing that up!

@bender@twtxt.net

Sorry, you’re right, I should have used numbers!

I’m don’t understand what “preserve the original hash” could mean other than “make sure there’s still a twt in the feed with that hash”. Maybe the text could be clarified somehow.

I’m also not sure what you mean by markdown already being part of it. Of course people can already use Markdown, just like presumably nothing stopped people from using (twt subjects) before they were formally described. But it’s not universal; e.g. as a jenny user I just see the plain text.

⤋ Read More
falsifian
www.falsifian.org
 (1y ago)
↳ In-reply-to » Okay folks, I've spent all day on this today, and I think its in "good enough"™ shape to share:

@prologic@twtxt.net Thanks for writing that up!

I hope it can remain a living document (or sequence of draft revisions) for a good long time while we figure out how this stuff works in practice.

I am not sure how I feel about all this being done at once, vs. letting conventions arise.

For example, even today I could reply to twt abc1234 with “(#abc1234) Edit: …” and I think all you humans would understand it as an edit to (#abc1234). Maybe eventually it would become a common enough convention that clients would start to support it explicitly.

Similarly we could just start using 11-digit hashes. We should iron out whether it’s sha256 or whatever but there’s no need get all the other stuff right at the same time.

I have similar thoughts about how some users could try out location-based replies in a backward-compatible way (append the replyto: stuff after the legacy (#hash) style).

However I recognize that I’m not the one implementing this stuff, and it’s less work to just have everything determined up front.

Misc comments (I haven’t read the whole thing):

  • Did you mean to make hashes hexadecimal? You lose 11 bits that way compared to base32. I’d suggest gaining 11 bits with base64 instead.

  • “Clients MUST preserve the original hash” — do you mean they MUST preserve the original twt?

  • Thanks for phrasing the bit about deletions so neutrally.

  • I don’t like the MUST in “Clients MUST follow the chain of reply-to references…”. If someone writes a client as a 40-line shell script that requires the user to piece together the threading themselves, IMO we shouldn’t declare the client non-conforming just because they didn’t get to all the bells and whistles.

  • Similarly I don’t like the MUST for user agents. For one thing, you might want to fetch a feed without revealing your identty. Also, it raises the bar for a minimal implementation (I’m again thinking again of the 40-line shell script).

  • For “who follows” lists: why must the long, random tokens be only valid for a limited time? Do you have a scenario in mind where they could leak?

  • Why can’t feeds be served over HTTP/1.0? Again, thinking about simple software. I recently tried implementing HTTP/1.1 and it wasn’t too bad, but 1.0 would have been slightly simpler.

  • Why get into the nitty-gritty about caching headers? This seems like generic advice for HTTP servers and clients.

  • I’m a little sad about other protocols being not recommended.

  • I don’t know how I feel about including markdown. I don’t mind too much that yarn users emit twts full of markdown, but I’m more of a plain text kind of person. Also it adds to the length. I wonder if putting a separate document would make more sense; that would also help with the length.

⤋ Read More
movq
www.uninformativ.de
 (1y ago)

Had to build a list of all feeds (that I follow) and all twts in them and there are two collisions already:

$ ./stats
Saw 58263 hashes
7fqcxaa
  https://twtxt.net/user/justamoment/twtxt.txt
  https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
  https://twtxt.net/user/prologic/twtxt.txt
  https://twtxt.net/user/thecanine/twtxt.txt

Namely:

$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa

[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic@twtxt.net I checked the GitHub discussion, it became a request to join forces.

Do you plan on having them join?

Also for the name, how about:

  • “progit” or “prologit” (prologic official hard fork)
  • “git-stance” (git instance)
  • “GitTree” (Gitea inspired, maybe to related)
  • “Gitomata” (git automata)
  • “Git.Source”
  • “Forgor” (forgit is taken so I forgor) 🤣
  • “SweetGit” (as salty chat)
  • “Pepper Git” (other ingredients) 😉
  • “GitHeart” (core of git with a GitHub sounding name)
  • “GitTaka” (With music in mind)

Ok, enough fun… Hope this helps sprout some ideas from others if nothing is to your taste.]

$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa

[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It’s handled by blue Monday]

And:

$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) <a href="https://txt.sour.is/external?uri=https://twtxt.net/user/prologic/twtxt.txt">@prologic<em>@twtxt.net</em></a> I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]

$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) <a href="https://txt.sour.is/external?uri=https://twtxt.net/user/shreyan/twtxt.txt">@shreyan<em>@twtxt.net</em></a>  Ahh 👌]

⤋ Read More
prologic
twtxt.net
 (1y ago)

👋 Reminder folks of the upcoming Yarn.social monthly online meetup:

I hope to see @david@collantes.us @movq@www.uninformativ.de @lyse@lyse.isobeef.org @xuu@txt.sour.is @sorenpeter@darch.dk and hopefully others too @aelaraji@aelaraji.com @falsifian@www.falsifian.org and anyone else that sees this! 🙏 We’re hopefully going to primarily discuss the future of Twtxt and the last few weeks of discussions 🤣

  • Event: Yarn.social Online Meetup
  • When: 28th September 2024 at 12:00pm UTC (midday)
  • Where: Mills Meet : Yarn.social
  • Cadence: 4th Saturday of every Month

Agenda:

  • Let’s talk about the upcoming changes to the Twtxt spec(s)

#Yarn.social #Meetup

⤋ Read More
sorenpeter
darch.dk
 (1y ago)
↳ In-reply-to » Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?

⤋ Read More
prologic
twtxt.net
 (1y ago)
↳ In-reply-to » @movq @falsifian @prologic Maybe I don't know what I'm talking about and You've probably already read this: Everything you need to know about the “Right to be forgotten” coming straight out of the EU's GDPR Website itself. It outlines the specific circumstances under which the right to be forgotten applies as well as reasons that trump the one's right to erasure ...etc.

@aelaraji@aelaraji.com This is one of the reasons why yarnd has a couple of settings with some sensible/sane defaults:

I could already imagine a couple of extreme cases where, somewhere, in this peaceful world one’s exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldn’t necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for… let’s just say ‘Their well being’, would it heart if a pod just purged their content if it’s serving it publicly (maybe relay the info to other pods) and call it a day? It doesn’t have to be about some law/convention somewhere … 🤷 I know! Too extreme, but I’ve seen news of people who’d gone to jail or got their lives ruined for as little as a silly joke. And it doesn’t even have to be about any of this.

There are two settings:

$ ./yarnd --help 2>&1 | grep max-cache
      --max-cache-fetchers int        set maximum numnber of fetchers to use for feed cache updates (default 10)
  -I, --max-cache-items int           maximum cache items (per feed source) of cached twts in memory (default 150)
  -C, --max-cache-ttl duration        maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)

So yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed’s Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered “old” and drop off the active cache.

It’s a feature that my old man @off_grid_living@twtxt.net was very strongly in support of, as was I back in the day of yarnd’s design (nothing particularly to do with Twtxt per se) that I’ve to this day stuck by – Even though there are some 😉 that have different views on this 🤣

⤋ Read More