Searching txt.sour.is

Twts matching #Gemini
Sort by: Newest, Oldest, Most Relevant

When I chose the MIT license for all of my software, I thought:

“Should I use GPL, which I don’t really understand? Is that worth it? Yeah, there is a theoretical possibility that some company might use my code in their proprietary product … and then what? Should I sue them to enforce the GPL? I’m not going to do that anyway, so I’ll just use the MIT license.”

And now we have those LLM scrapers and now it’s suddenly a reality that these companies (ab)use my code. I can see it in my logs. I didn’t expect that back then.

GPL wouldn’t help, either, of course. (Regardless, I now think that GPL would have been the better choice anyway.)

I’m honestly considering taking my code and website offline. Maybe make it accessible through some obscure protocol like Gopher or Gemini, but no more HTTP.

(Yes, Anubis might help. Temporarily.)

I’m just tired.

⤋ Read More

well, I assume by syntax you mean Gemtext (which I like a lot, my personal blog is built on top of it), so I think it might work for twtxt clients…

I knew of twtxt in Gemini Antenna, so at least the 2017 spec might work on that protocol. I think the main issue with extensions is that they weren’t designed with many URLs and protocols in mind.

Also I have to admit that the Gemini community significantly reduced in the last few years. I don’t know how worth it is to add support for Gemini now.

⤋ Read More

Timeline and twtxt-php, don’t support Gemini, only HTTP/S, as a design choice (although originally it was intended to work on Gemtext, it was a niche inside a niche, so it was discarded very soon).

At the moment of building the engine there weren’t many Gemini URLs supporting twtxt 1.1 (with twtxt.dev extensions).
Also User-Agent won’t work there, and many Gemini URLs are a mirror of the HTTP one, so I think is not strictly necessary.

my 2c

⤋ Read More

well, Gemini clients like Lagrange allow to show inline images when you click on an image link. Text based clients, like Amfora, usually allow to watch the image in another ‘window’.

For example here: gemini://text.eapl.mx/en-making-a-tic-tac-toe-variant and there https://text.eapl.mx/en-making-a-tic-tac-toe-variant

I agree that some topics require images to make it easier to explain.

⤋ Read More

@eapl.me@eapl.me here are my replies (somewhat similar to Lyse’s and James’)

  1. Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax ![NSFW](url.to/image.jpg) if something is NSFW

  2. IDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.

  3. Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.

  4. Discovery: User-agent for discovery can become better. I’m working on a wrapper script in PHP, so you don’t need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that’s the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.

  5. Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs

  6. Languages: If the need is big then make a separate feed. I don’t mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it’s about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.

  7. Emojis: I’m not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?

⤋ Read More

Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:

  1. It’s a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.

  2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.

  3. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).

  4. Do we need more commandments?

⤋ Read More

I was not suggesting to that everyone need to setup a working webfinger endpoint, but that we take the format of nick+(sub)domain as base for generating the hashed together with the message date and content.

If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt … damn I just notice the gemini. subdomain.

Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?

⤋ Read More

how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well

⤋ Read More

Google Chrome will have Gemini LLM built into the browser.

⤋ Read More

@fastidious@arrakis.netbros.com the things Gemini has going for it are mutual TLS and lack of JavaScript. Which makes for a secure albeit boring experience (much like gopher). The fake markdown is a bit of a drag.

A render mode for Gemini probably wouldnt be too hard. There are markdown to Gemini libs out there.

With Web3 the whole trust a 3rd party browser ext + high fees + env impact for compute and storage are serious no gos for me.. I have heard one too many horror stories about clicking the wrong link and some script draining your metamask wallet.

⤋ Read More