💾 Archived View for gemi.dev › gemini-mailing-list › 000367.gmi captured on 2024-08-25 at 11:18:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I have recently started writing a protocol that could be used for distributing gemini content among different servers. The final idea would be that people could share information in a distributed manner. You can find more about it here: gemini://idf.looting.uk/capslog/invis.gemini
It would be really helpful if you could mock up feeds for modules A, B, and C, where A is joining, B & C are existing, and A attaches to B. In particular, the feed content at the start, for A, B, and C, along with artefacts produced during and after merge. This could be done dynamically with actual code, or just visually with before/after file contents. I think there's a lot of potential in the concept. Discovery is, in my opinion, the biggest issue of the Internet, and it's been woefully neglected (probably because algorithms stepped in and distracted us with ruthless efficiency!) While aggregators and search engines are good, they ultimately present us with lists of stuff that's often only loosely related. This can be fun in itself, but there's lots more we could innovate on. Kevin On Wed, 9 Sep 2020 at 22:11, <idf31 at memeware.net> wrote: > I have recently started writing a protocol that could be used for > distributing gemini content among different servers. The final idea > would be that people could share information in a distributed manner. > You can find more about it here: > > gemini://idf.looting.uk/capslog/invis.gemini > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/83df d02d/attachment.htm>
twtxt seems more aligned with the mindset of Gemini, and is already supported by gemini servers and clients. Can we adapt twtxt instead of reinventing the wheel, I don't think it gets simpler than that anyway. Just a text file with one line for tweets. One advantage is that only the clients are involved and if I don't check your feed, there is no cost. Or is the plan for the servers to be more actively involved like Fedi? -- Leo
I'd argue that, for the moment at least, the more wheels being invented, the better! As I see it, all current wheels are square (ok, maybe some are octogonal). What we have is many services copying Twitter and Facebook, yet communication is a very nuanced thing - something they have taken and distilled, genetically modified, mass-produced, and used to flood the market. Yet, real human communication is truly nuanced. Consider the difference between a joke well told vs badly told, sometimes it's not even the words, it's just the timing, or intonation. There's a lot to explore to move from being merely 'engaging' to 'enriching'. Kevin On Thu, 10 Sep 2020 at 06:40, Leo <list at gkbrk.com> wrote: > twtxt seems more aligned with the mindset of Gemini, and is already > supported by gemini servers and clients. > > Can we adapt twtxt instead of reinventing the wheel, I don't think it gets > simpler than that anyway. Just a text file with one line for tweets. > > One advantage is that only the clients are involved and if I don't check > your feed, there is no cost. Or is the plan for the servers to be more > actively involved like Fedi? > > -- > Leo > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/bd8f 6b85/attachment.htm>
On 2020-09-10 08:39, Leo wrote: > twtxt seems more aligned with the mindset of Gemini, and is already > supported by gemini servers and clients. > > Can we adapt twtxt instead of reinventing the wheel, I don't think it > gets simpler than that anyway. Just a text file with one line for > tweets. > > One advantage is that only the clients are involved and if I don't > check your feed, there is no cost. Or is the plan for the servers to > be more actively involved like Fedi? > > -- > Leo It seems I haven't really made the intent of the protocol clear, I apologise. InVis is not an attempt to reinvent social media like twitter or facebook or whatever. And I agree with you that there are a lot of clones for these things. In more general terms, InVis should provide a way for Gemini servers to mirror each other's content. It should provide a way for Geminauts to make their content available to a wider space, and to provide a nice way of archiving as a side-effect. I think this could increase the discoverability of content, since a reader would be presented with a much wider library of content from other people than just the people that run that one server the reader stumbled upon. All that is needed to read an InVis module is a Gemini client, since all InVis would do is to mirror gemtext files between servers :) Again, I apologise for the misunderstanding, I will try to update the draft soon.
What I kinda want when I hear the words "Gemini Fediverse" is a Gemini interface to the existing Fediverse. Like Brutaldon, but for Gemini instead of Lynx. ActivityPub is a nightmare but that nightmare can be encapsulated server side and clients only need to be able to do basic Gemini stuff?
Sandra Snan <sandra.snan at idiomdrottning.org> writes: > What I kinda want when I hear the words "Gemini Fediverse" is a Gemini > interface to the existing Fediverse. Like Brutaldon, but for Gemini > instead of Lynx. Hi, I'm the author of brutaldon :) I've thought about writing a Gemini Mastodon/Pleroma client, like brutaldon for Gemini. It would be extremely straightforward to do read-only, public-timelines-only. Slightly less straightforward to do read-only, personal timelines (need to handle Mastodon login process, generate a client key, and link it to Mastodon auth token). Once you've got that done, text-only posting with your default privacy level is easy, but adding images, polls, and privacy settings becomes difficult because of the intentional limitations of Gemini input fields. IMO you're really better off using either Toot (TUI) or Tootstream (CLI), though. I don't really love the idea of Gemini being used intensively for applications, because it's intentionally not designed for it. I feel like the 'Gemini way' for doing network application development is to design an open, application-specific protocol, and write native servers and clients for it. NNTP is the example I always keep coming back to. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
---