~soywod/pimalaya

4 3

New Pimalaya app proposal

Details
Message ID
<finger-name-proposal@aasrud.com>
DKIM signature
pass
Download raw message
Hi Pimalaya folks,

My friend [Victor][0] (he's in the Matrix room) gave me this idea a
while ago, and I have been thinking quite a bit about it since. It's a
modern take on the [Name/Finger protocol][1] that would allow users to
easily share information they want to make public with other users on
the network. Think stuff like your name, email, PGP keys, etc. Nothing
you wouldn't share on your homepage. Additionally, we could add a
feature where users could share their current status, which would then
be displayed on a central feed containing all the newest status
messages, kinda like <status.cafe>.

Before diving into development, I wanted to get your input and feedback.
What features could be included? What types of technologies and
solutions should be utilized (HTTP might be the simplest, but there
might be better options)? The latter point also ties into a difficult
problem: Is there a way to avoid making it a hosted solution? The data
stored would obviously be quite small and not very sensitive, but I
still think it would be nice to avoid centralizing the data. The cost of
hosting would also be a concern.

I think such an app would be a great fit for the Pimalaya project, but
there are many things that need to be ironed out before starting. If you
have any ideas or suggestions, please don't hesitate to share them!

[0]: https://glorifiedgluer.com/about
[1]: https://en.wikipedia.org/wiki/Finger_(protocol)

-- 
Best,
Magnus
Details
Message ID
<87cz3pmot4.fsf@posteo.net>
In-Reply-To
<finger-name-proposal@aasrud.com> (view parent)
DKIM signature
pass
Download raw message
> My friend Victor gave me this idea a while ago, and I have been
> thinking quite a bit about it since. It's a modern take on the
> Name/Finger protocol that would allow users to easily share
> information they want to make public with other users on the
> network. Think stuff like your name, email, PGP keys, etc. Nothing you
> wouldn't share on your homepage. Additionally, we could add a feature
> where users could share their current status, which would then be
> displayed on a central feed containing all the newest status messages,
> kinda like <status.cafe>.

I did not know about the name/finger protocol, really interesting. And
Victor's idea makes a lot of sense! Love it.

> Before diving into development, I wanted to get your input and
> feedback. What features could be included?

I think proposing a server and a client could be a good first step (a
bit like the fingerd daemon and the finger CLI).

> What types of technologies and
> solutions should be utilized (HTTP might be the simplest, but there
> might be better options)?

HTTP sounds great, this way we could fetch informations from web sites
also.

> The latter point also ties into a difficult problem: Is there a way to
> avoid making it a hosted solution? The data stored would obviously be
> quite small and not very sensitive, but I still think it would be nice
> to avoid centralizing the data. The cost of hosting would also be a
> concern.

Good point indeed, it needs to be well designed. I will think about it
and come back later with some ideas.

> I think such an app would be a great fit for the Pimalaya project, but
> there are many things that need to be ironed out before starting. If you
> have any ideas or suggestions, please don't hesitate to share them!

Totally in!! I am pretty sure it could also fit the NLnet program for a
donation.
Details
Message ID
<06e79058-5fe1-4440-b849-ee37d4a03786@aasrud.com>
In-Reply-To
<87cz3pmot4.fsf@posteo.net> (view parent)
DKIM signature
pass
Download raw message
Glad to hear you like the idea Clement!

I now have a *very rudimentary* server/client implementation in the 
[source code][1] which just uses local TCP sockets to communicate, which 
should be easy to port into remote communication.

There is a case to be made that we may not need to follow the HTTP 
protocol at all if all communication is supposed to be done via the toe 
tooling. We could just have our own simple commands. However, if we want 
interoperability with something like curl, then we have no choice. Also, 
adding a security layer would probably be easier if we can utilize 
already existing HTTPS implementations, so I guess we should just give 
in.

[1]: git.sr.ht/~kmaasrud/toe
Details
Message ID
<2027228646.1094659.1683056745822@office.mailbox.org>
In-Reply-To
<finger-name-proposal@aasrud.com> (view parent)
DKIM signature
missing
Download raw message
Hello, this is an interesting idea indeed

> [...] Think stuff like your name, email, PGP keys, etc. Nothing you
> wouldn't share on your homepage. Additionally, we could add a
> feature where users could share their current status, which would
> then be displayed on a central feed containing all the newest status
> messages, kinda like <status.cafe>.

This sounds a lot like WebFinger[0]. Look at the "Identity Provider
Discovery for OpenID Connect" section on its RFC[1]

> What features could be included? What types of technologies and
> solutions should be utilized (HTTP might be the simplest, but there
> might be better options)?

I think that HTTP is enough for this. I can't really think of a better
protocol for such task.

> The latter point also ties into a difficult problem: Is there a way
> to avoid making it a hosted solution? The data stored would
> obviously be quite small and not very sensitive, but I still think
> it would be nice to avoid centralizing the data. The cost of hosting
> would also be a concern.

I don't think we can avoid hosting altogether. It will either be a
*paid* service or you host it yourself.

> I think such an app would be a great fit for the Pimalaya project,
> but there are many things that need to be ironed out before
> starting. If you have any ideas or suggestions, please don't
> hesitate to share them!

Considering how WebFinger works, it might be enough for this project.
What could be accomplished here is a way to manage the multiple things
it can represent.

[0]: https://webfinger.net/ [1]:
https://datatracker.ietf.org/doc/html/rfc7033#section-3.1

--
Victor Freire
Details
Message ID
<36e3493e-91a5-466a-b191-a22c087d9f74@aasrud.com>
In-Reply-To
<2027228646.1094659.1683056745822@office.mailbox.org> (view parent)
DKIM signature
pass
Download raw message
> This sounds a lot like WebFinger[0]. Look at the "Identity Provider
> Discovery for OpenID Connect" section on its RFC

I hadn't heard about WebFinger before, but it seems perfect for the job.
Why reinvent the wheel when there's already a standard for it, right? I
found an existing implementation [0], but it is outdated and hasn't
changed in a while. As such, I did the only sensible thing (not) and
started our own WebFinger implementation [here][1]. The protocol is
relatively small, so it shouldn't be that much of an undertaking.

I actually think WebFinger might be a good fit for contact discovery in
Himalaya (or cardamom, when that is ressurected), so this might bear
fruit in other areas as well.

> I don't think we can avoid hosting altogether. It will either be a
> *paid* service or you host it yourself.

Yeah, you're right.

[0]: https://docs.rs/webfinger
[1]: https://git.sr.ht/~kmaasrud/pimalaya-webfinger
Reply to thread Export thread (mbox)